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>

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.