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

Debugging configure

[mopslik]

...what to do when an automatic configuration script doesn't work.

I've written a little program that debugs configure automatically. To compile my program, simply run configure, then run ... oh, wait. Never mind.

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.

The webpage missed a major resource

[devphil]

The GNU Autotools have their own published book, the electronic edition of which is online. This doesn't seem to be listed in the resources at the end of the article.

Backwards

[devphil]

Rather than attempting to include support for every architecture via autoconf,
[...]
Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly,

That's exactly how autoconf doesn't work. "Including support for every architecture" is how previous build systems worked, like xmake. Those were an unmitigated disaster.

Automake's goal is to allow the build system to adapt itself to whatever system happens to be available. It does not look at the OS and say, hey, I'm on Solaris, bring out these hardcoded settings. Instead it performs tests for each feature of interest -- where is the compiler? where are the SSL libraries? what's the exact function signature for this not-quite-standard-C subroutine? If your system has been customized from the factory default, so to speak, then hardcoded answers will be wrong, no matter how dilligently those porting people were in originally deriving them.

The idea is to have configure discover whatever the correct answers are, and set variables appropriately so that you don't have to care about the differences -- you can write the code once, as you say, and let the automatics do the necessary adjustments, rather than other people. Assume you're running on a POSIX system, for example, and let configure #define things as necessary to make up for the non-POSIX systems.

tips and tricks

[devphil]

The "code for checking" is all just a bunch of macros. Believe me, the slowdown you see isn't the shell reading a bunch of lines of text.

Some points that might speed things up:

• Some shells suck. The generated configure is designed to not require any modern shell features (in case you run it on some ancient piece of crap), so you can use whatever stripped-down streamlined implementation of Bourne shell you want. (Assuming the developers of whatever package you're installing haven't used such features themselves, and most don't, for the same reasons that autoconf recommends.)
• Some shells really suck. Under Solaris and AIX, for example, /bin/sh is such a flaming piece of shit that people running non-trivial configures are advised to run configure with a different shell.
• If you're getting the same results for commonly-used tests, strip them out of the generated cache, keep the cache around, and when you go to run a new package, preload the cache. (Can be tricky, but is usually safe. Just cache the safe stuff like, "checking if CPU is on fire... no".
• On recent Linux systems, a big slowdown is the part at the very end, when files like Makefile and config.h are being created. These are basically huge sed operations. Recent versions of sed and glibc have really taken a performance hit in this area. (Depends on your distro. Some sed's are compiled with their own regex engine, some use glibc's. There're more details, but I'm pressed for time.) You might try timing the last part (running config.status over and over to get an average time), then putting a different sed in your PATH and trying again. I found old versions of "ssed" to really kick ass.