| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
LCA: Disintermediating distributions
LCA: Disintermediating distributions
Posted Feb 7, 2008 0:28 UTC (Thu) by stevenj (subscriber, #421)In reply to: LCA: Disintermediating distributions by vmole
Parent article: LCA: Disintermediating distributions
In my experience with developing many actual programs using autoconf, the checks in the configure script are a direct consequence of porting to some platform or another. ("Crap, MinGW doesn't support gettimeofday, we'll need to check for it and whatever alternative is available.")
Most new code these days assumes C89 support at least, and doesn't check any more for functions like "strcpy". On the other hand, as recently as a few years ago the default Solaris compiler didn't support "const" by default unless you jumped through hoops, and hence a lot of programs had checks for things like that.
It's true that, at some point, older programs might be able to remove checks for things that only break on ancient platforms, but it can be really hard to decide exactly when to remove such checks. It's safer to leave them in and wait the extra seconds than to break the build on an extant architecture.
Regarding the time for configure to run, its true that the configure script is often slower these days than compiling the program. For large programs, parallel make speeds up things a lot, while parallelizing configure tests is extremely tricky (although it has been discussed a lot by the autoconf developers). For small projects, the configure script may call the compiler more times than the Makefile itself, but long experience has shown that actually trying to compile something in the configure script is by far the most reliable way of performing a feature test. In any case, the number of times that one has to run "configure" is small (most people don't run it at all anymore, since prepackaged binaries from distros are ubiquitous), and it's better to sacrifice a little build time than to sacrifice robustness.
(Log in to post comments)
LCA: Disintermediating distributions
Posted Feb 7, 2008 0:52 UTC (Thu) by vmole (subscriber, #111) [Link]
In my experience with developing many actual programs using autoconf, the checks in the configure script are a direct consequence of porting to some platform or another.
My experience says otherwise. Things like checking C++ related stuff (and even Fortran!) in projects that are pure C. And the sucessful checks for C89 followed by checks for individual C89 standardized functions is widespread, and almost certainly because there's some autoconf macro that does all of it. It's just stupid and annoying.
LCA: Disintermediating distributions
Posted Feb 7, 2008 1:40 UTC (Thu) by stevenj (subscriber, #421) [Link]
The checks for C++ and Fortran in C-only programs was due to a libtool 1.5 bug that has since been fixed, IIRC.
And it's true that AC_PROG_CC (the check for a C compiler) automatically calls a check to make sure the compiler is in C89 (ISO C90) mode, and if not it tries to find an option to put the compiler in C89 mode. Reliably checking whether the compiler is in C89 mode involves, among other things, checks for stdio.h. These checks were still required fairly recently — e.g. on AIX circa 2003 you had to use "-qlanglvl=extc89" or it didn't handle macro parameters in completely ANSI fashion, and on HPUX the compiler was non-ANSI by default until at least the late 90s. And many of these systems were still running long, long after their release dates (e.g. I heard from Solaris users with a compiler that defaulted non-ANSI as recently as a few years ago).
When autoconf has a default check, there's usually a good reason for it; most developers don't have experience on a wide enough variety of platforms to appreciate this. Try to get a patch accepted into autoconf sometime and you'll see what they have to deal with and why so many complaints about autoconf are founded in ignorance.
(And if your configure time is dominated by the default check for an ANSI compiler, your project is pretty small indeed. As I said, in my experience most configure scripts times for projects of decent size are dominated by checks that the programmers explicitly included in response to portability problems --- or by checks that are invoked by those checks like the case above, which the autoconf developers put in there for good reason. And, really, it's not like this is a huge problem—how often do you run configure scripts, and how many seconds would you be willing to shave off at the risk of losing portability to some machine?)
LCA: Disintermediating distributions
Posted Feb 7, 2008 7:51 UTC (Thu) by aleXXX (subscriber, #2742) [Link]
> In my experience with developing many actual programs using autoconf,
> the checks in the configure script are a direct consequence of porting
> to some platform or another. ("Crap, MinGW doesn't support
> gettimeofday, we'll need to check for it and whatever alternative is
> available.")
Yes, basically the configure checks are necessary.
Autoconf itself wasn't so bad. But then additionally you have to
understand how it works together with automake and libtool. This is what
made it really hard for me.
And I'm sure this is also the reason why many programs run much more
configure checks than they actually need. They take the autotools stuff
from some existing project and just change it so that it can build their
program. With this approach you end up with all the configure checks the
original script had, and maybe later on you have to add some more. IMO it
is simply too hard to build a simple program using autotools. Who wants
to learn that just to build hello world ?
Using other build systems, as e.g. cmake, makes this trivial:
add_program(helloworld hello.c)
That's all, cmake will do a few checks to find the compiler, check that
it actually works and figure out if it's a 32 or 64 bit compiler, and
that's all.
I guess for Scons it's similar.
Also autotools don't doesn't push you to use some modular style, at least
in KDE we ended up with a few huge scripts which did a lot of magic. E.g.
CMake strongly encourages a modular system (while it is of course still
possible to throw everything into one file, but then you intentionally
work around its features).
Alex