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
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?
Basically caching the results, but also moving the code for checking for the conditions to the users machine rather than pregenerated on the developers machine.
When I run configure it often says stuff like "check...(cached)" but configure still runs slow as molasses - so I'm not sure what exactly it is doing..
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)
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)
unless the configure script is senile and bootstraps itself from YOUR local autoconf (which is just programmer laziness).
Tell the maintainer of your troubles... it needs to be fixed.
autoconf/automake are self-contained, and should only need to be used for building your own configure scripts, or for setting up packages from CVS.
Fuck Beta. Fuck Dice
some linux programs are *terrible* for doing this:
#include <linux/someheader.h>
instead of
#include <machine/someheader.h>
and then you have to hunt it all down. What's the point of having configure?
This makes it a pain to use on e.g. FreeBSD.
I just move off of HP-UX. ;-)
(If only I had that luxury)
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)
Make itself is badly underspecified. POSIX Make simply doesn't scale well enough to support a medium-sized or larger project; it doesn't standardize anything like dependancy tracking or including other makefile fragments.
As a result, every implementation of make grew its own features to handle the deficiencies. Including files, to take your example, can be done with every make program out there -- but the syntax, and the exact behavioral semantics, is subtly different across all the implementations. So it's very easy to get wrong.
(That's one of the reasons why I like automake. It handles a lot of that for me, generating a makefile.in which doesn't depend on GNU make or BSD make or whatever.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Check out the 'modules' program at modules.sourceforge.net. It makes it fairly easy to switch between versions of any program you like (and choose to set up with modules).