I have a moderate C++ project. I'm trying to use autotools for it, but find the complexity overwhelming.
What are guidelines for when to use autotools and when you can do without it? What are (simple) alternatives?
The main reason I want to use autotools is for its full make install support. Is there a simpler alternative?
Ideally, I'd like something supported by Eclipse CDT.
For the make install support, you only need automake. And a simple Makefile.am file is quite easy to make:
LIBS += -lsome-lib -lsome_other_lib
bin_PROGRAMS = hello
noinst_HEADERS = some.h header.h files.h
hello_SOURCES = hello.c some.c other.c source.c file.c
That's about it.
The autoconf tool is useful if you want to make your program more platform-independent. You write a simple script to test the existence of the system header files and system libraries you use. If not found you either give an error or use copies provided in your package.
For trivial, self-contained (no dependencies, nothing to be installed), projects with up to 3 source code files, write a Makefile:
.PHONY: all clean
all: program
clean:
rm -f *.o
program: sourceA.o sourceB.o
$(CXX) -o $@ $^ $(LDFLAGS)
You can define variables for CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS, at least GNU make fills in the blanks in the expected way.
It of course doesn't address the problem of dependency tracking, nor checking for system capabilities. A common problem for non-trivial projects is to interact with the system: making sure certain libraries are usable, and installing/uninstalling. Most tools fail on both.
Here's a few examples I have experience with:
It generates consistent project files for different IDEs (and also Makefiles if you just need to build the code). Doesn't do anything else (no install target, no way to check for availability of libraries). Only useful if you need to supply project files for an IDE that you don't use (e.g. you use Eclipse and somebody else wants to compile it on Visual Studio). Anything non-trivial requires LUA scripting.
If all you need is to call the compiler to process your files, it's acceptable. For almost anything you'll have to memorize (or copy/paste) sequences of low-level macros (which form a programming language of sorts). Finding libraries on the system is convoluted and messy (some libraries were blessed by the creators and have hard-coded tests to find them, so you might be lucky). Considering the amount of broken cmake scripts I had to deal with to this date, I think most people just copy/paste the macros around without trying to understand it. Can install, but not uninstall. With some cmake scripts you might have to run cmake multiple times until it generates the correct output (e.g. VTK).
Seems to be CMAKE and Premake done better: no macros, uses a well-known programming language (Python) to provide a fair amount of useful functionality. Still fails in a number of ways; specifying a non-hardcoded installation prefix requires non-trivial effort, because it's not built-in.
Does far more than the tools mentioned above. And most of them, conveniently. Has sane defaults; some highlights:
AC_CHECK_LIB(foobar, function_to_check_linking) - this finds a library named foobar, and put it in the $LIBS environment variable. Yes, detecting libraries is an important common task; if your tool doesn't consider this a first-class use-case, ditch it. (It's more convenient to use PKG_CHECK_MODULES though.)
Every action during ./configure is logged in config.log, so you can actually figure out what went wrong. For most other tools, at best you'll get "Boost_dir-NOTFOUND".
Already comes with built-in make install, make uninstall (what do you mean, your tool can put stuffs on my system but can't remove them?), make check (if you specified test_ programs), make dist-gzip (packages the source files into a tar.gz), make distcheck (creates a tar.gz and makes sure everything builds correctly and all tests pass). Even better, it plays nicely with checkinstall so you can create and distribute .rpms and .debs from it.
You can mix in good old Makefile rules inside automake Makefiles if needed.
Autotools files are tracked as well as source files, so helper scripts and Makefiles are generated again if needed, by simply invoking make.
Yes, it's "hard" to learn, but no more than learning all the specific macros/functions to call in CMAKE/SCons, in my opinion. An initial Makefile.am for a project is just a list of files assigned to a variable, and an initial configure.ac can be generated by autoscan; I find it convenient even for more trivial projects.
The autobook is the best source I know to learn it, but it's unfortunately outdated (autoconf will complain a lot about using deprecated macros).
You can pick and choose the parts of autotools that you want to use. Many projects use only autoconf, the part of autotools that generates a configure script, and if you just want to generate a Makefile with an install target that is configurable by the end user, then that's probably all you need.
I don't know if this is too far off answer-wise, but I'd consider scons. It takes a bit to get going, but does many, many things automatically that has to be hand-teased with make.
