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

Re:You talk to the developer

[GigsVT]

Well the danger with that, is the authors being deluged by people who just don't have the right dependancies installed.

Of course, it could be considered a bug if the configure script fails silently or ambiguously just because a dependancy was missing, but I see it a lot.

It'd really help if the authors would put very verbose missing dependancy messages, even as far as including a URL for the dependancies, if they aren't common.

One build that comes to mind that was total hell was Flightgear. That thing has dependancies all over the place, and not common things either.

Re:Debugging configure

[jamsho]

If configure fails the first thing to do is rm -R <the sources dir>, unpack sources and try again.... this can clean up some bugs involving the temporary files and the cache configure creates when it's run.... especially if you've run configure inside that source tree before.

Infact I NEVER run configure in the same source tree twice (still smarting after bitter 2 days debugging experience that got resolved by doing exactly the above ... :)

Re:Ports

[Anonymous Coward]

Ah, an interesting example. You see, I recently tried to evaluate your BSDiff program. Not only could I not build it, I couldn't even figure out how to modify it to make it build - because you haven't even tried to write portable code.

For example, you rely on BSD make. That makes some sense for a BSD project, of course. But BSD make is not available on Cygwin. If you don't want to use the more widely available GNU make and its extensions, you could at least restrict your makefile to the subset of constructs that all make utilities support.

In short, I'm sticking with the portable binary diff utility, xdelta. I'm sure BSDiff is as much better as you claim, but as I can't use it, that's not much good to me, is it?

Re:configure.in parsing

[Anonymous Coward]

Would it be possible to have a program that read configure.in files directly, worked out what they were testing for etc, and just returned the right values?

This is what the pre-make-kit project (http://pmk.sf.net) is trying do to. The project aims to provide an alternative to autoconf. You should have a look.

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.