Why do the autotools suck?

Started by
33 comments, last by Strife 18 years, 10 months ago
Quote:Original post by 255
I've taken the (long) time needed to learn autotools and Makefiles and IMHO it has been worth it.

Agreed.
Quote:Original post by Sneftel
The autotools are horrible because:

1. All open-source software that evolves for this long without being rewritten from scratch is horrible, to some extent.
2. They're designed to run E-VAH-RY-WHERE, with minimal software support. The extra complexity that this requires is mind-boggling.
3. They were developed in the macros-on-macros-on-target-language style common to the time (see TeX), which inevitably leads to a laundry list of ugly side effects and gotchas (see TeX).

Also, agreed :P.

The autotools have a very steep learning curve that needn't be there. However, once I overcame it, I was very happy to continue using them due to their overall versatility and usefulness, not to mention their "standard" status amongst the *nix community.
Advertisement
So I've now decided that what I would perhaps like to do is take a look at the code Anjuta (and maybe KDevelop, too) uses to generate the configure scripts and makefiles. I might even rip that code and create a small Gtk app that will do only that part (i.e., you tell it what type of project you want, it sets up the autoconf and automake input files accordingly).

Basically, I want to save myself time, but I also want to be able to keep the universality that the autotools provide.

If anyone has any comments or suggestions on this idea, please let me know. I'd like to start it once I get my current project off the ground a little bit.
The last time I looked KDevelop and Anjuta created configure.in according to old standards. Nowadays you are supposed to use the name configure.ac and some things in the beginning file should be diffrent. Then again if you code only for the newest autotool versions, developers working on older distros may not be able to recreate the configure script.

autoupdate and running autoconf and automake with -Wall will help you get rid of deprecated constructs.
I read something recently that configure.ac is what the newest version of autoconf looks for specifically. The reason for this is that there are various things about the newest version that are incompatible with older versions.

As such, the newest version is not uber-standard yet. Many systems (even newer ones) continue to use older versions that "prefer" configure.in.

As far as the autotools go, newer is not necessarily better.
Personally, I consider autotools crap and obsolete.

Basically, I run ./configure and see something like

Checking if your compiler works ... yes...


WHY do I care? If my compiler doesn't work, I'll find out soon enough.

Autoconf is a really bad kludgy solution to a problem which doesn't exist any more (i.e. how to make code which builds on a zillion unix flavours).

I don't care if my code doesn't build on Irix, Xenix, Flibbleix, SCO Unix (in fact, I'd prefer it if I didn't), or even Solaris.

If I'm coding for Linux, I'll assume that people are using Linux. I'll write a Makefile which makes assumptions about every library.

If I find that I need to build it on several platforms, I'll write one Makefile for each, including the common bits.

Other issues will be solved as they go. Autotools is way too complicated and sucky.

Mark
i use a bash script to compile all files ending in .cpp under src/ into obj/, then link them all at the end. i make a makefile to execute the command.
heres the tree
helloworld/	data/	doc/	obj/	src/	make	Makefile


for anyone whos interested, heres the make script
#!/bin/shOPT="-Isrc/ -include src/types/stlext.h -include src/types/macro.h	-include src/types/fs.h	-DDEBUG"LIB="-llua -llualib -lSDL -lSDL_image -lboost_filesystem-gcc"# look through all cpp filesfor cppsrc in `find src -name '*.cpp'`; do	objsrc=obj/`basename ${cppsrc%.cpp}`.o	echo "$cppsrc => $objsrc"	# does object file already exist?	if [ -f $objsrc ]; then		if [ $cppsrc -nt $objsrc ]; then # is it newer than cpp src?			g++ -c $cppsrc -o $objsrc $OPT		fi	else		g++ -c $cppsrc -o $objsrc $OPT	fidone# now link all the cpp files togetherg++ -o grid obj/*.o $LIB


personally I think the speed of the build and the clarity is far better.
Quote:Original post by Genjix
i use a bash script to compile all files ending in .cpp under src/ into obj/, then link them all at the end. i make a makefile to execute the command.
heres the tree
helloworld/	data/	doc/	obj/	src/	make	Makefile


for anyone whos interested, heres the make script
*** Source Snippet Removed ***

personally I think the speed of the build and the clarity is far better.


I like it. I may yoink that and use it.

Obviously, with that you can still get in some problems if libs or headers are stored in weird places, but let's face it. If your Unix system places its headers or libs in a weird place, that's your problem.
Quote:Original post by markr
Personally, I consider autotools crap and obsolete.

Basically, I run ./configure and see something like

Checking if your compiler works ... yes...


WHY do I care? If my compiler doesn't work, I'll find out soon enough.


WHY you would care ? Your users are going to have a really hard time when they get a cryptic gcc error message, and have no fucking clue what to do. If you however detect that the build is going to fail in the configure script, you can at least give them a decent error message (something like libxxx missing go to www.libxxx.com and install it).

Of course if you don't distribute your software as source code, this doesn't apply. In which case you probably are better of with something like scons.

"THE INFORMATION CONTAINED IN THIS REPORT IS CLASSIFIED; DO NOT GO TO FOX NEWS TO READ OR OBTAIN A COPY." , the pentagon
Quote:Original post by markr
Personally, I consider autotools crap and obsolete.

Basically, I run ./configure and see something like
Checking if your compiler works ... yes...

WHY do I care? If my compiler doesn't work, I'll find out soon enough.

Because that is, of course, the only message you see. That's all configure does, check to see that your compiler works.

It doesn't check to see what libraries you have installed, and it isn't able to switch between prefered versions if equivalents exist.

It can't check if particular header files exist and prevent them being included if they don't exist. After all, everyone that uses Linux has libxxx installed, so it's fine if you just assume that it's there.
Quote:
Autoconf is a really bad kludgy solution to a problem which doesn't exist any more (i.e. how to make code which builds on a zillion unix flavours).

Phew. Portability problems have been completely resolved. Looks like there was a silver bullet, after all.
Quote:
I don't care if my code doesn't build on Irix, Xenix, Flibbleix, SCO Unix (in fact, I'd prefer it if I didn't), or even Solaris.

And because you don't care about it, nobody else should. Right on!
Quote:
If I'm coding for Linux, I'll assume that people are using Linux. I'll write a Makefile which makes assumptions about every library.

That's certainly the way to write a widely used program. Yes sir. Don't be put off by fact that not even all Linux systems are the same and your program won't work on more esoteric distributions.
Quote:
If I find that I need to build it on several platforms, I'll write one Makefile for each, including the common bits.

That's a really good idea. After all, there are only a handful of platforms, so it's reasonable to maintain seperate Makefiles for each. And, of course the "platform" is the correct quantum of portability: if a program can be compiled on one Linux, it can be compiled on all Linuxes, since every installation of every Linux distro is exactly the same.
Quote:
Other issues will be solved as they go. Autotools is way too complicated and sucky.

You're right!

The autotools pointlessly make it easier to write programs that can be compiled on almost any *NIX system, even systems which the original programmer didn't know existed.

They also pointlessly have support for standardised options for make targets, compilation options and installation directories. Those certainly don't help an administrator who needs to install hundreds of packages with particular features enabled into a site-specific filesystem layout.

You are correct to assume that because you don't personally find autotools useful, nobody else possibly could.

Just in case it isn't clear. THAT WAS IRONY.
autotools scare me.

I did however manage to become pretty competent at writing Makefiles.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.

This topic is closed to new replies.

Advertisement