# Why do the autotools suck?

## Recommended Posts

Strife    374
So I've been around Linux for a long time, but I've resisted learning the autotools. Why? Because they're complicated as hell. I really don't want to spend an extra 30 minutes having to remind myself what all the damn macros are and then writing the files just so that I can compile my programs. I'm not really a huge fan of the IDEs that exist for Linux, but one thing I do like about them is that they let me not have to worry about writing any of this configure.in, Makefile.am, etc. BS. It's really a shame that the rest of the IDEs suck. So here's what I would like to know. Does there exist any type of standalone tool that can perform the creation of the makefiles for me? If not, I suppose I'll have to continue using a full-blown IDE just to generate makefiles while using vim to edit my source files...

##### Share on other sites
dave    2187
I've written make files in linux for compiling C code and i honestly didnt find it that hard by hand. Should i be assuming that you are compiling alot of code? I was compiling about 10 CPPs.

ace

##### Share on other sites
255    368
I've taken the (long) time needed to learn autotools and Makefiles and IMHO it has been worth it. Their scripted nature allow you to do just about anything. For example it was very simple to have a python script generate source files from csv tables and do it so that
a) when I modify the script or the csv file, the source files get regenerated and rebuilt
b) make clean does not remove the source files (so python is not required to compile the distributed tarball)

Autotools also has the advantage that the configure script makes the package easily adaptable to nearly any unix setup. This is, of course, only important for open source projects.

I've found the easiest way to get started is google for some configure.ac, Makefile.am and autogen.sh files to use as templates.

It would be nice if some GUI (or why not CLI) program existed to create the templates. After that all the programmer would normally have to worry about is listing new files into Makefile.am.

##### Share on other sites
Sneftel    1788
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).

The thing is, though, they're standards. And they're not going anywhere, at least in the next few years. Suck it up and use the autotools.

##### Share on other sites
rollo    366
I'm not to fond of the autotools either, so I was very happy when I found SCons (www.scons.org). It works much like autoconf/automake, but in nice python code instead of hard to remember AM macros. I'm using it for all my projects instead of the autotools and have no regrets over the switch. Id used it for the linux port of Doom 3 as well.

##### Share on other sites
silmaril    175
CMake is also worth taking a look at, even though the main advantage for cmake is that it generates build files for systems without make as well, such as visual studio project files. The CMake scripts are rather easy to write, and it even got a GUI for configurating it. I use it for all my projects that are either on linux only or cross-platform these days, and is very pleased with it.

##### Share on other sites
mrhollow    136
It was a pain, but when I finally learned to use autotools, it was tremendous. My program was suddenly a _real_ linux utility with a standard install:

./configure
make
make install

I suppose it depends what you are distributing. If it's a utility you would like to have show up in distros, autotools are going to be the best way to get wide adoption. If you are working on games, something else is probably in order.

My only experience with scons was that it got stuck compiling something (Presumably a loop) and almost took the system down with it before I manually killed it...

##### Share on other sites
b34r    365
One of the problems being that every Unix and Linux distro out there wants to layout the system its very own way.

But whatever, Autotools is utter crap especially with SCONS around. I'm not a makefile wizard so I'm sure I can't see all the beauty there is to Autotools but 500k of autogenerated scripts for a Hello World makefile is simply unacceptable.

Going over the Autotools manual a long time ago left me with the impression that you could 1) program or 2)write makefiles but not both. Autotools are *not* auto \:.

##### Share on other sites
Strife    374
Oh, I don't want the autotools to disappear. I want a program that will generate the input files for me (much as Anjuta and KDevelop do, I just want this to be done without the suck).

Quote:
 Original post by 255It would be nice if some GUI (or why not CLI) program existed to create the templates. After that all the programmer would normally have to worry about is listing new files into Makefile.am.

That is *exactly* what I want.

Basically, I just don't want to be spending my time editing files just so I can build my project. I want to just have stuff ready for me, where all I really need to do is maybe add a few libraries to link against here and there, and that be it.

Is that really so much to ask for? Anyone who's used an IDE has been able to do this for years.

##### Share on other sites
Strife    374
Quote:
 Original post by silmarilCMake is also worth taking a look at, even though the main advantage for cmake is that it generates build files for systems without make as well, such as visual studio project files. The CMake scripts are rather easy to write, and it even got a GUI for configurating it. I use it for all my projects that are either on linux only or cross-platform these days, and is very pleased with it.

Looking into CMake briefly, it looks like it might be what I'm looking for. However, I can't seem to find the little GUI for it. Is the GUI Windows-only or something? The web site isn't too clear on that...

Turns out, that's what ccmake is for. A curses "GUI" for it.

##### Share on other sites
Null and Void    1088
Quote:
 Original post by 255I've taken the (long) time needed to learn autotools and Makefiles and IMHO it has been worth it.

Agreed.
Quote:
 Original post by SneftelThe 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.

##### Share on other sites
Strife    374
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.

##### Share on other sites
255    368
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.

##### Share on other sites
Strife    374
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.

##### Share on other sites
markr    1692
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

##### Share on other sites
Genjix    100
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. #### Share this post ##### Link to post ##### Share on other sites Strife 374 Quote:  Original post by Genjixi 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 treehelloworld/ data/ doc/ obj/ src/ make Makefilefor 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. #### Share this post ##### Link to post ##### Share on other sites George2 187 Quote:  Original post by markrPersonally, I consider autotools crap and obsolete.Basically, I run ./configure and see something likeChecking 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. #### Share this post ##### Link to post ##### Share on other sites Nathan Baum 1027 Quote:  Original post by markrPersonally, I consider autotools crap and obsolete.Basically, I run ./configure and see something likeChecking 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. #### Share this post ##### Link to post ##### Share on other sites smart_idiot 1298 autotools scare me. I did however manage to become pretty competent at writing Makefiles. #### Share this post ##### Link to post ##### Share on other sites Strife 374 Quote:  Original post by Nathan BaumJust in case it isn't clear. THAT WAS IRONY. Nah, that was sarcasm. #### Share this post ##### Link to post ##### Share on other sites Boder 938 I have this huge directory of pictures with an infinite number of subdirectories. Is there a way to recursively copy all the folders and files without going through and making a Makefile.am for each one? Not to mention having to output tons of Makefiles when calling AC_OUTPUT... To clarify, I want this to happen for "make install" #### Share this post ##### Link to post ##### Share on other sites Nathan Baum 1027 Quote: Original post by Strife Quote:  Original post by Nathan BaumJust in case it isn't clear. THAT WAS IRONY. Nah, that was sarcasm. An American lectures me on irony? [wink] Webster says -- Irony: A sort of humor, ridicule, or light sarcasm, which adopts a mode of speech the meaning of which is contrary to the literal sense of the words. #### Share this post ##### Link to post ##### Share on other sites 255 368 Quote:  Original post by BoderI have this huge directory of pictures with an infinite number of subdirectories.Is there a way to recursively copy all the folders and files without going through and making a Makefile.am for each one? Not to mention having to output tons of Makefiles when calling AC_OUTPUT...To clarify, I want this to happen for "make install" You could have configure store a list of your files in an automake variable via AC_SUBST, which you can then add to your _DATA target. You can use find or some other command to generate the list. #### Share this post ##### Link to post ##### Share on other sites Guest Anonymous Poster Quote:  Original post by BoderI have this huge directory of pictures with an infinite number of subdirectories.Is there a way to recursively copy all the folders and files without going through and making a Makefile.am for each one? Not to mention having to output tons of Makefiles when calling AC_OUTPUT...To clarify, I want this to happen for "make install" "cp -R$(pkgdatadir)", perhaps? Put it in an install-data-local target.

Although, given that you have an infinite number of subdirectories, I'm not sure I want you copying them to my disk, anyway.