Debugging Configure

An anonymous reader writes "All too often, checking the README of a package yields only the none-too-specific "Build Instructions: Run configure, then run make." But what about when that doesn't work? In this article, the author discusses what to do when an automatic configuration script doesn't work -- and what you can do as a developer to keep failures to a minimum. After all, if your build process doesn't work, users are just as badly off as if your program doesn't work once it's built."

Comments

You talk to the developer

[samjam]

You send configure.log and the failure message to the developers, who hopefully understand autoconf a bit more and why it failed.

Some projects you can't find the developers, then its time to learn how autoconf works and read the autoconf mailing lists and work out what test failed and why.

Most tests fail because
* some required feature is not supported on your platform,
* or because the configure script is old and autoconf has been updated

The latter is sadly quite common in badly maintained projects as autoconf has undergone revisions and badly written autoconf definitions have started failing.

If your platform lacks a feature you write around it for your platform with "ifdefs" which get activiated according the the test failure. I dont know how to do this, fortunatly for me all my projects have been working under people who understand autoconf quite well.

Sam

Re:You talk to the developer

[anthony_dipierro]

First I always put the last line or two of error messages into google. 8 times out of 10, I find someone asking the same question, and usually someone has already posted an answer.

Actually, before even that I check with Linux From Scratch (and Beyond LFS). But there are a whole lot of packages they don't cover.

Ports

[cperciva]

Rather than attempting to include support for every architecture via autoconf, I think the BSD ports approach is far superior: Write code once, and have people put together their own sets of patches, makefile wrappers, et cetera to fit their own architecture.

For example, I wrote my binary patching tool on FreeBSD, but I don't recommend that people (even on FreeBSD) build it directly from the source tarball; instead, I advise people to use the ports tree, since that puts BSDiff into FreeBSD's packaging system. If someone running Gentoo wants to use BSDiff, they can install it from portage, which adds workarounds for gmake and linux breakage.

Most developers only have access to a couple platforms for testing their code. Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly, and allow other people to step in and provide the necessary patches and packaging to support other platforms.

Re:I find configure quite useful

[cperciva]

Editing Makefiles (or Imakefiles if you are lucky) is often like "reading core dumps", as someone put it.

Makefiles are often poorly written. In particular, people very often fail to use .include directives properly.

If you want to see well-written Makefiles, look in the BSD source tree. Taking one at random, here's FreeBSD's src/usr.sbin/edquota/Makefile:

# @(#)Makefile 8.1 (Berkeley) 6/6/93
# $FreeBSD: /repoman/r/ncvs/src/usr.sbin/edquota/Makefile,v 1.8 2003/04/04 17:49:13 obrien Exp $

PROG= edquota
MAN= edquota.8

WARNS?= 4

.include <bsd.prog.mk>

Autoheadache

[dmelomed]

"aid that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time."

If autoconf is so problematic and PITA, why use it in the first place?
autoconf/make is more trouble than it's worth. Portable makefiles and small portability test programs is the right way to do it.

Some people just don't value complexity enough. These tools are needlessly complex. This page has more info: http://www.ohse.de/uwe/articles/aal.html

Re:Backwards

[aminorex]

And you're saying that automake is NOT an
unmitigated disaster?

In my view any project that needs to resort
to automake in order to configure the build
environment has already failed. It has failed
to deliver a portable Makefile, and failed to
deliver portable application source code,
and tried to work around that failure after
the fact by patching it with automake.

Re:Backwards

[devphil]

And you're saying that automake is NOT an unmitigated disaster?

Huh? When did this switch from autoconf to automake? Okay, sure, I'll play. I think automake is a fine tool.

In my view any project that needs to resort to automake in order to configure the build environment

Your view is wrong, since that's not what automake is for. That's autoconf's job.

It has failed to deliver a portable Makefile,

Here you're clearly talking out of your ass. Go look at a generated Makefile.in. It's whole purpose in life is to be more portable than any hand-written makefile could ever be. Go ahead, try to implement the same complicated, real-world-necessary rule patterns yourself, without resorting to a nonportable feature of GNU make, or BSD make, or Sun make, or...

The point is to save typing during the input (Makefile.am) and yet keep the output (Makefile.in/Makefile) utterly portable. And it succeeds admirably. What, you'd rather force everyone to maintain hundreds of lines of makefile by hand?

and failed to deliver portable application source code,

What the fuck does that have to do with the makefile? Or the build system? This is a red herring, and a specious argument.

and tried to work around that failure after the fact by patching it with automake.

...a tool which, in fact, does not actually patch any files. Brilliant argument there, buddy. Perhaps you should pay attention to which tool does what.

Feh. Go back to your hand-written tedious makefiles. I'll stick with tiny free-form automake files. And add you to my /. killfile.

Re:Backwards

[bazongis]

I so totally agree with the parent post like I've never agreed with a slashdot post before ;)

Sure, for small and simple programs you can resort to hand-crafted Makefiles and just skip all that autofoo business, no question.

But once you bring stuff like multiple libraries (even if it's just no-install static libraries) or conditional compilation (enable/disable features that rely on certain libraries for example) into the equation, you'll have an extremely hard time getting this right on most platforms with a hand-crafted Makefile.

Not to mention different versions of the tools required on one and the same platform.

Also, let's not forget that most developers do not have 15 boxes with different architectures/OSes to play around with at home. If you have the expertise and know about all those different platforms and operating systems and their respective quirks, you sure have my respect. I don't think that's particularly common though.

I really don't understand why everyone is complaining about the autofoo suite. It works great most of the time, and when it fails, it usually fails in known ways.

Re:Backwards

[Brandybuck]

You're both right and wrong.

You're right in that xmake and similar systems didn't work well. You're right in that an automatic configuration system should query for capabilities.

But you're wrong in that autoconf/automake is the answer. I tried to build some software yesterday and I got the error that I wasn't using the correct version of automake. WTF! When the specific versions of automake/autoconf are themselves configuration variables, something's seriously wrong.

Re:least favourite thing to have to change is...

[anarxia]

Headers under include/linux are not guaranteed to work between kernel versions and that's why they need to be avoided. In fact it is not recommended to use them (except if you are libc). The headers are under include/linux because they ARE linux kernel headers and not because somebody wanted to break compatibility with BSD.

For example, the joystick interface used to be pretty much the same as BSD (linux 2.0 era) but not anymore (the new interface is much better but that's another story). If linux used machine/joystick.h it would give the illusion of a uniform interface between linux and BSD but this is not always the case.

Any application using linux or machine headers should either make them optional (at the expence of some functionality or performance) or stop claiming portability.

Re:I find configure quite useful

[juhaz]

That may be simple and well written, but it only needs to compile on FreeBSD.

What if you have a package that has to work on FreeBSD AND OpenBSD AND Linux AND bazillion other unixes AND win32/cygwin AND win32/mingw AND .... gazillion other os/library/whatever combinations.

It won't be that simple any more, and at that point it's probably impossible to "write well" as well.

Huh?

[devphil]

"aid that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time."

I don't know of any aspect of computer programming that's both non-trivial and easy to accomplish, when you're going it for the first time.

If autoconf is so problematic and PITA, why use it in the first place? autoconf/make is more trouble than it's worth.

You know, I've never had that much trouble with it. I've never had more trouble than doing it by hand would have given me.

I've certainly never found a different system that saves me more time while maintaining the degree of portability required for most of our projects. I'm sure if we decided that "all the world's a PC," or even "all the world runs Linux," we could do it by hand, but that's not good enough.

Portable makefiles and small portability test programs is the right way to do it.

I couldn't agree more. That's why I use a generator of insanely portable makefiles (it's a tool called automake), and a tool which creates and runs small portability test programs (it's called autoconf).