I’ve been asked over on Twitter if I had any particular tutorial for an easy one-stop-shop tutorial for Autotools newbies… the answer was no, but I will try to make up for it by writing this post.
First of all, with the name autotools, we include quite a bit of different tools. If you have a very simple program (not hellow-simple, but still simple), you definitely want to use at the very least two:
automake. While you could use the former without the latter, you really don’t want to. This means that you need two files:
The first of the two files (
configure.ac) is processed to produce a
configure script which the user will be executing at build time. It is also the bane of most people because, if you look at one for a complex project, you’ll see lots of content (and logic) and next to no comments on what things do. Lots of it is cargo-culting and I’m afraid I cannot help but just show you a possible basic
AC_INIT([myproject], , [email@example.com], [https://flameeyes.blog/tag/autotools-mythbuster/]) AM_INIT_AUTOMAKE([foreign no-dist-gz dist-xz]) AC_PROG_CC AC_OUTPUT([Makefile])
Let me explain. The first two lines are used to initialize
automake respectively. The former is being told the name and version of the project, the place to report bugs, and an URL for the package to use in documentation. The latter is told that we’re not a GNU project (seriously, this is important — you wouldn’t believe how many tarballs I find with 0-sized files just because they are mandatory in the default GNU layout; even though I found at least one crazy package lately that wanted to have a 0-sized NEWS file), and that we want a
.tar.xz tarball and not a
.tar.gz one (which is the default).
After initializing the tools, you need to, at the very least, ask for a C compiler. You could have asked for a C++ compiler as well, but I’ll leave that as an exercise to the reader. Finally, you got to tell it to output
Makefile (it’ll use
Makefile.in but we’ll create
Makefile.am instead soon).
To build a program, you need then to create a
Makefile.am similar to this:
bin_PROGRAMS = hellow dist_doc_DATA = README
Here we’re telling
automake that we have a program called
hellow (which sources are by default
hellow.c) which has to be installed in the binary directory, and a
README file that has to be distributed in the tarball and installed as a documentation piece. Yes this is really enough as a very basic
If you were to have two programs,
hellou, and a convenience library between the two you could do it this way:
bin_PROGRAMS = hellow hellou hellow_SOURCES = src/hellow.c hellow_LDADD = libhello.a hellou_SOURCES = src/hellou.c hellow_LDADD = libhello.a noinst_LIBRARIES = libhello.a libhello_a_SOURCES = lib/libhello.c lib/libhello.h dist_doc_DATA = README
But then you’d have to add
AC_PROG_RANLIB to the
configure.ac calls. My suggestion is that if you want to link things statically and it’s just one or two files, just go for building it twice… it can actually makes it faster to build (one less serialization step) and with the new LTO options it should very well improve the optimization as well.
As you can see, this is really easy when done on the basis… I’ll keep writing a few more posts with easy solutions, and probably next week I’ll integrate all of this in Autotools Mythbuster and update the ebook with an “easy how to” as an appendix.