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."
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.
I think that this is the easy way out, this way the author of the original code can simply ignore the other plataforms. I think that the author should be consient that other plataforms do exists and he should actively try to separate code that is plataform dependent into separate files or libs. And learning autoconf do help to learn where the pifalls are.
Said that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time.
[]'s Victor Bogado da Silva Lins
^[:wq
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)
Supporting GNU make is laudable because it is
by far the most portable and ubiquitous build
system in the world.
Portability is laudable because it allows
people to use your code.
If using GNU make could be a barrier to the
adoption of your code, that might be a reason
not to use it, but the license of GNU make
doesn't have any obvious bearing on the
usability of your application which is built
by its mechanisms.
-I like my women like I like my tea: green-
'make clean' better trash the configure cache files, or someone didn't write their make files correctly. I've been using the same source trees for apache, postfix, ssh.com's ssh2, and bind for years, along with FreeBSD stable sources. Never once have I had a configure problem that 'make clean' didn't resolve.
"Why do you consent to live in ignorance and fear?" - Bad Religion