Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Kamp: A Generation Lost in the Bazaar
Posted Aug 20, 2012 15:21 UTC (Mon) by corbet (editor, #1)
Posted Aug 20, 2012 18:10 UTC (Mon) by samroberts (subscriber, #46749)
Posted Aug 20, 2012 19:43 UTC (Mon) by wahern (subscriber, #37304)
In the modern context, the value of autotools and similar is less, and the relative cost higher.
The bigger issue today is remaining "portable" between Linux and Windows. That causes many times more headaches than in even the most backwards of Makefile hacks.
Posted Aug 20, 2012 21:23 UTC (Mon) by cmccabe (guest, #60281)
The so-called portability of autotools is a mirage, anyway. autotools requires you to write portable shell scripts in order to be portable. Since most developers couldn't do this to save their lives, it is effectively Linux-only.
Posted Aug 20, 2012 22:29 UTC (Mon) by nix (subscriber, #2304)
Posted Aug 20, 2012 22:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Aug 21, 2012 1:11 UTC (Tue) by cmccabe (guest, #60281)
There's something non-portable about this one. Can you spot what it is?
Posted Aug 21, 2012 2:04 UTC (Tue) by hummassa (subscriber, #307)
Posted Aug 21, 2012 5:38 UTC (Tue) by pbonzini (subscriber, #60935)
But it's otherwise a very well-written configure.ac
Posted Aug 21, 2012 20:40 UTC (Tue) by cmccabe (guest, #60281)
By the way, gtest has since switched to CMake.
Posted Aug 21, 2012 22:36 UTC (Tue) by nix (subscriber, #2304)
(Arguing that Autoconf is awful because it includes shell fragments is also vitiated in the presence of a project that uses any manually-written shell scripts at all. As most do.)
Posted Aug 22, 2012 6:15 UTC (Wed) by cmccabe (guest, #60281)
And yes, the kernel component is Linux-only, but there are other ways to access the filesystem.
> (Arguing that Autoconf is awful because it includes shell
> fragments is also vitiated in the presence of a project
> that uses any manually-written shell scripts at all. As
> most do.)
All the standalone shell scripts that are currently in the Ceph server repo are used for testing purposes. That's why they're in directories with names like 'qa', 'test', and so forth. Later on, the project started moving more towards Python for testing... but I digress.
Would you be ok with a build system that required you to write Makefiles in C? Oh, but your project includes .c files, so your arguments are vitiated. Come on, this is absurd, and you know it.
Posted Aug 22, 2012 7:40 UTC (Wed) by cmccabe (guest, #60281)
Posted Aug 22, 2012 13:38 UTC (Wed) by nix (subscriber, #2304)
What I was trying to point out is that the nonportability of shell script is a bad argument against autoconf if you use any other shell script in your source tree, because you are just as likely to introduce nonportabilities there as in the configure.ac (and they would be just as hard to detect). The portability or otherwise of C is irrelevant to this argument: your objection is a non sequitur.
configure scripts depend on the shell environment in any case, so allowing you to introduce your own shell fragments introduces no new dependencies, which was very important to the Autoconf designers. (Again, the manual *says* all this. This is not secret hidden knowledge.)
Posted Aug 22, 2012 18:27 UTC (Wed) by cmccabe (guest, #60281)
Again, this is not a binary choice between plain old Makefiles and autotools. My choice is CMake.
CMake has its own scripting language which is portable across platforms (including Windows), versioned, and specifically designed for this use-case. Using the policy mechanism you can tell CMake "act as if you were CMake 2.6." Anyone with a version of CMake higher than or equal to 2.6 can then compile your project exactly as you intended. Shell scripts don't have any of these things.
Yes, shell scripts are appropriate for some use cases. But a build system is just not one of them. Let's use the right tool for the job rather than trying to explain how with a little duct tape, a plunger can be used as a hairbrush.
At the end of the day, nothing can make your code portable but you. But the build system can help you or hurt you. If it closes off platforms to you, like autotools closes off Windows to you, that hurts. If it forces you to write shell scripts to do everything, that hurts portability too. I've spent a long time fixing build breakages that resulted from autotools' poor choices. The question of what kind of Makefile.am or configure.ac a superintelligent Zen master who has studied AIX, IRIX, csh, tcsh, bash, zsh, dash, and every other shell out there might write is not interesting to me. In the real world, autotools = not portable.
Posted Aug 22, 2012 19:21 UTC (Wed) by hummassa (subscriber, #307)
Posted Aug 22, 2012 20:17 UTC (Wed) by boudewijn (subscriber, #14185)
Really, people who have an opinion on cmake and autotools in relation to windows, whether it's with mingw, msvc, or icc, but haven't checked out the way the kde-windows project uses cmake should check it out. Doing that will make their life _much_ easier.
Posted Aug 24, 2012 1:16 UTC (Fri) by cmccabe (guest, #60281)
Various projects may have trouble with cross-compiling, because their authors did something problematic (like assuming that they could build a binary with the target compiler and then run it, or using hard-coded paths in a dumb way). However, this is just as true with autotools. Fix the bugs and move on.
Posted Aug 23, 2012 5:46 UTC (Thu) by quotemstr (subscriber, #45331)
I read the chapter and decided to ignore it. I'm not interested in working around ancient HP-UX bugs or supporting systems too old to have decent support for here-documents.
Posted Aug 21, 2012 0:33 UTC (Tue) by HelloWorld (guest, #56129)
Posted Aug 21, 2012 1:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Scons and waf are also nice.
Posted Aug 21, 2012 11:42 UTC (Tue) by cortana (subscriber, #24596)
Some day I hope to use a build system that does not make me pine for the autotools, but that day has not yet come to pass.
Posted Aug 21, 2012 11:46 UTC (Tue) by cortana (subscriber, #24596)
1. Project developers
2. End users (who simply want to build the project)
3. Translators (who need rules for extracting, merging and updating translations)
4. Porters (who want to cross compile to another system, or build with a native toolchain on another system)
CMake and other systems that are sadly popular such as SCons or waf, fall over when considering the needs of those who aren't project developers themselves. For all its warts, autotools is the only system that caters adequately to the needs of all of the above groups.
Posted Aug 21, 2012 14:06 UTC (Tue) by hummassa (subscriber, #307)
Posted Aug 21, 2012 15:27 UTC (Tue) by pboddie (subscriber, #50784)
I've seen quite a bit of build system evolution and apathy towards cross-compiling in my time - just search the Python bug-tracker for the debris of attempts to get Python's build system to stop doing "I need to run myself on the host now!" and actually work for cross-compilation - and hoping that target devices will be powerful enough for everyone to forget about cross-compilation isn't a useful strategy.
I suppose people can argue that the "anarchy" has not only resulted in the construction of autotools - a dubious claim, since autotools does consider things that later tools ignore or miss, and thus does seem to have had some thought given to its functionality - but also the lack of maintenance of autotools and the proliferation of other tools that don't always measure up. Those things have more to do with the perceived cost of fixing things or developing new things than any particular development strategy, though.
Posted Aug 21, 2012 14:22 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Autotools at most is an equal-opportunity serial murder, which chooses its victims from any of the four listed groups indiscriminately.
Posted Aug 22, 2012 17:21 UTC (Wed) by dashesy (subscriber, #74652)
Posted Aug 23, 2012 22:09 UTC (Thu) by nix (subscriber, #2304)
Posted Aug 21, 2012 18:22 UTC (Tue) by boudewijn (subscriber, #14185)
On the other hand, the cmake systems for all the dozens of dependencies I used in that case had been tested in KDE's wonderful emerge project beforehand, and that helped a lot.
Posted Aug 21, 2012 8:05 UTC (Tue) by BlueLightning (subscriber, #38978)
Posted Aug 20, 2012 22:55 UTC (Mon) by marcH (subscriber, #57642)
Wow, a quadruple negation. Totally appropriate for a discussion about autotools; well done!
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds