Update: I converted this post in a new GnomeGoal, see here
Update 2: Added some more tips
Autotools is the most common system to build programs in GTK+/GNOME projects.
Remove deprecated macros for our configure.ac file and use the new syntax will do our build system more legible and portable
The Autotools comes with a program to make the work for us, simply run
autoupdate
in you source tree and you have a new updated configure.ac. (Checks the result for possibles errors)
Some more tips:
- Respect the standard configure.ac layout
- Try to avoid the use of AM_MAINTAINER_MODE. AM_MAINTAINER_MODE (called like that) disables dependency-checking for autotools-generated stuff. AM_MAINTAINER_MODE([enabled]) retains the default behavior, but lets users pass a configure option to disable the dependency checking. So, if you really need this macro, use AM_MAINTAINER_MODE([enabled]). See the automake manual for a extended explanation
- Use all the parameters of AC_INIT() (for the fifth parameter you need autoconf >= 2.64):
AC_INIT([Glom],[1.13.2],[http://bugzilla.gnome.org/enter_bug.cgi?product=Glom],[glom],[http://www.glom.org/])
- Use updated versions of the programs (all of these versions (and newer) are present in Debian stable):
- automake >= 1.11.1 (AM_INIT_AUTOMAKE([1.11.1])) (or 1.10.3, Automake < 1.10.3 and 1.11 are known to be suffering from critical security issues)
- autoconf >= 2.64 (AC_PREREQ(2.64))
- libtool >= 2.2.6 (LT_PREREQ([2.2.6]))
- intltool >= 0.40.0 (IT_PROG_INTLTOOL([0.40.0]))
- Take a look to all AM_INIT_AUTOMAKE() posible parameters. For example, to use 1.11.1 automake version and generate bzip2 distribution tarballs in addition to the gzip’ed:
AM_INIT_AUTOMAKE([1.11.1 dist-bzip2])
- Use LT_INIT() syntax for libtool (needs libtool >= 2.2.0). More info about LT_INIT(). For example, change this:
AC_LIBTOOL_DLOPEN AC_LIBTOOL_WIN32_DLL AC_DISABLE_STATIC AM_PROG_LIBTOOL
For this:
LT_PREREQ([2.2.6]) LT_INIT([dlopen win32-dll disable-static])
- Don’t use GNOME_COMMON_INIT, as it does not work with autoreconf. Simply add this to your Makefile.am. (You have to define the macros dir in your configure.ac, in this case: AC_CONFIG_MACRO_DIR([m4]))
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
- Use gnome-common macros for compile warnings macros instead custom ones. Also use GNOME_MAINTAINER_MODE_DEFINES to get warnings when using deprecated symbols:
GNOME_COMPILE_WARNINGS([maximum]) GNOME_CXX_WARNINGS([yes]) GNOME_MAINTAINER_MODE_DEFINES
Other tips
Feel free to suggest more tips in the comments!
Some documentation:
Interesante información. ¡Estaría bien si tu blog estuviera el http://planeta.es.gnome.org/ y http://planet.gnome.org!
Some more hints:
Use dist_foo_BAR to avoid pulling everything via EXTRA_DIST:
scriptsdir = $(bindir)
dist_scripts_SCRIPTS = script1 script2
http://www.gnu.org/software/automake/manual/automake.html#Fine_002dgrained-Distribution-Control
Pass dist-bzip2 to AM_INIT_AUTOMAKE to generate bzip2 distribution tarballs in addition to the gzip’ed:
AM_INIT_AUTOMAKE([… dist-bzip2])
Use silent rules and AM_V_GEN for custom compilation:
autoconf: AM_SILENT_RULES([yes])
automake: $(AM_V_GEN) custom-compil-tool …
http://www.gnu.org/software/automake/manual/automake.html#Fine_002dgrained-Distribution-Control/am_v_gen/
@Juanjo Marin: Me has dado una idea … 😉
@Mike Thank you for the tips!
The use of silent rules is already a GnomeGoal: http://live.gnome.org/GnomeGoals/NicerBuilds
Feel free to add more tips in the GnomeGoal page
Regards
Why not dropping autotools in favor of CMake (or another one) instead of improving them? It’s a very high barrier of entry to new developers.
@Andrés, If you are interested, maybe It’s a good idea talk with some project maintainer and make a patch to use CMake instead autotools, so everybody can see the benefits and/or drawbacks of the change.
Some time ago I did some search about this topis [1]. I only found 2 GTK+ projects that use CMake: gtkpod and inkscape (If you know any other, please tell me)
[1] http://live.gnome.org/JavierJardon/NewBuildSystem
@Andrés, why would Gnome want to switch to CMake? From my experience with it, it’s a pretty rubbish system… I had a lot of trouble with it. For example, it couldn’t even do pkg-config without a 3rd party script.
I find Autotools to be nicer, as long as you do it properly (that is, non-recursively)
The only way to modernize autotools is not to use them…
libtool is not 2.2.6 in Debian stable: 1.5.26-4+lenny1
http://packages.debian.org/lenny/libtool
autoconf is not 2.63 in Debian stable: 2.61-8
http://packages.debian.org/lenny/autoconf
@Neil, both packages are available in lenny backports:
http://packages.debian.org/lenny-backports/libtool
http://packages.debian.org/lenny-backports/autoconf
Why don’t you just move away from autohell and move to cmake like sane people?
Please don’t move to cmake. It is very clunky to use with pkg-config. Autotools may be inconvenient but it works well in *nix environments.