Benefits of Using Auto Tuners and Spare Parts

Question

I have an average C ++ project. I try to use autotools for it, but find the complexity overwhelming.

What are the recommendations for using Autotools and when can you do without it? What are (simple) alternatives?

The main reason I want to use autotools is the full support of make install . Is there a simpler alternative?

Ideally, I would like something supported by the Eclipse CDT.

Answer 1

To support make install you only need automake . And the simple Makefile.am file is quite simple:

 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 

What about that.

---

The autoconf tool is useful if you want to make your program more platform independent. You are writing a simple script to check for the presence of system header files and system libraries that you use. If you did not find it, you either give an error or use the copies provided in your package.

Answer 2

For trivial, stand-alone (no dependencies, nothing to install) projects with three 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 gaps with the expected way.

Of course, he does not consider the problem of tracking dependencies and does not check the capabilities of the system. A common problem for non-trivial projects is the interaction with the system: ensuring the use of certain libraries and installing / uninstalling. Most tools do not work on both.

Here are some examples I come across:

Premake

It generates consistent project files for different IDEs (as well as Makefiles if you just need to create code). It does nothing else (there is no installation goal, there is no way to check for libraries). Useful only if you need to provide project files for the IDE that you are not using (for example, you are using Eclipse and someone else wants to compile it in Visual Studio). For something non-trivial, an LUA script is required.

CMake

If you only need to call the compiler to process your files, this is acceptable. For almost everything you need to remember (or copy / paste) low-level macro sequences (which form a variety programming language). Finding libraries in the system is confusing and messy (some libraries were blessed by the creators and have hard-coded tests to find them, so you might be lucky). Given the number of broken cmake scripts that I had to deal with before this date, I think most people just copy / paste macros without trying to figure it out. You can install but not uninstall. With some cmake scripts, you may have to run cmake several times until it generates the correct output (e.g. VTK).

Scons

CMAKE and Premake seem to have done better: no macros, use the well-known programming language (Python) to provide enough useful functions. Still failing in several ways; specifying a non-strict installation prefix requires a non-trivial effort because it is not built-in.

Autotools

This is much more than the tools mentioned above. And most of them are convenient. It has normal defaults; Some highlights:

• AC_CHECK_LIB(foobar, function_to_check_linking) - this finds a library named foobar and puts it in the $LIBS environment variable. Yes, library discovery is an important common task; if your tool does not consider this a first-class use case, drop it. (It's more convenient to use PKG_CHECK_MODULES, though.)

• Every action during ./configure logged in config.log , so you can actually figure out what went wrong. For most other tools, at best you will get "Boost_dir-NOTFOUND".

• There is already a built-in make install , make uninstall (what do you mean, your tool can put files on my system but cannot delete them?), make check (if you specified test_ ), make dist-gzip (source packages in tar.gz), make distcheck (creates tar.gz and ensures that everything is built correctly and all tests pass). Even better, it plays great with checkinstall , so you can create and distribute .rpms and .debs from it.

• You can mix in the old old Makefile rules inside automake Makefiles, if necessary.

• Autotools files as well as source files are tracked, so helper scripts and Makefiles are generated if necessary by simply calling make .

Yes, it is "difficult" to learn, but, in my opinion, nothing more than the study of all the specific macros / functions to call in CMAKE / SCons. The initial Makefile.am for the project is simply a list of the files assigned to the variable, and the initial configure.ac can be generated by autoscan ; I find this convenient even for simpler projects.

autobook is the best source I know to recognize it, but it is unfortunately outdated (autoconf will complain a lot about using outdated macros).

Answer 3

You can select and select the auto parts you want to use. Many projects only use autoconf , the autotools part that generates the configure script, and if you just want to generate a Makefile with an install target that is configured by the end user, then this is probably all you need.

Answer 4

I do not know whether it is too far from an answer, but I would think about the Brazilians. It takes a little bit to go, but does a lot, a lot of things automatically that you need to tease with make.