Slashdot Mirror
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."
I've written a little program that debugs configure automatically. To compile my program, simply run configure, then run ... oh, wait. Never mind.
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
blog.sam.liddicott.com
Personally, I like configure. Editing Makefiles (or Imakefiles if you are lucky) is often like "reading core dumps", as someone put it. Maybe it depends on which system you run (Linux in x86 is probably mainstream and well tested). The automated configure process only failed my once, where the created script was about testing one feature but failed on another issue. Reading the log (as suggested by the author) solved the case. Plus, most problems arise after a system update, when some files/dev-packages/stuff are still missing. Once you get an application successfully through configure, similar apps should work as well.
;)
It's still better to see something like "Testing for SSL... failed" than go "Can't locate libmcop_mt.so -- Huh? What child is this? Let's google..."
And if all else failes, remove the problematic code in configure, make, make install && pray
My cats ate my karma. They also wrote this comment.
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.
Tarsnap: Online backups for the truly paranoid
"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
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
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:
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
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.
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.
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).
You cannot apply a technological solution to a sociological problem. (Edwards' Law)