The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Autotools

From Allegro Wiki
Jump to: navigation, search

Allegro autotools reanimation project

Autotools (autoconf, automake, aclocal, libtool, pkg-config, ...) are very powerful utilities that can make cross-platform compilation ( and cross-compilation) fully customizable, safe and easy to use.

However, the current state of autotools support is not very good, the scripts are too complicated for not very good reasons (ASM routines, per architecture optimization -- things that are pretty useless now). On the other hand, ross compilation doesn't work, which is a shame.

Autotools are multiplatform (Linux, other unix-like OSs, Mac and Windows are supported). If this build setup would work, it could help programmers to make multiplatform games more easily.

What are those autotools?

From Wikipedia: The GNU build system, also known as the Autotools, is a suite of programming tools produced by the GNU project. These tools are designed to assist in making various source code packages portable to many Unix-like systems.

The GNU build system comprises the GNU utility programs Autoconf, Automake, and Libtool. Other related tools frequently used with the GNU build system are GNU’s make program, GNU gettext, pkg-config, and the GNU Compiler Collection, also called GCC.

Briefly: Autoconf checks whether you are able to acutally compile the program, Automake makes it easy to define what should be built, libtool makes dealing with libraries across platforms. pkg-config makes it easy for developers to use the program (if it is a library) if they use autotools themselves.

Pros & cons & misconceptions

Pros

  • Autotools are multiplatform (Unix, Windows, BeOS, Mac etc.)
  • You can configure all details of your build you need
  • You usually get a comprehensive error message if the build would fail
  • Package compilation and installation/uninstallation is extremely easy (for the end user)
  • The package distribution tarball is done and tested for you
  • package maintainers love autotools

Cons

  • Autotools are not easy to learn. You can write a deffective setup and then autotools seem to be the source of problems
  • Windows users who would like to compile the library would have to install MSYS (http://www.mingw.org/) if they want to benefit from autotools support

Misconceptions

  • You need to have autotools installed

No, you need just a bash-like environment

  • Autotools are too complicated, arcane and broken and whatever

Probably not, see this funny thread

  • Autotools makes builds slow.

Maybe it can be little bit slower than makefiles tuned by hand, but the building from scratch is rare enough. If you are a developer, you probably use your favourite IDE, but you run your configure script only once. Then if you alter any files, only units that are needed are rebuilt.

The former Allegro autotools support was not correct (talking about today's standards). The concept behind autotools is very smart.

How things are

Current state

Now there are following files used:

  • configure.in
File containing plenty of tests as m4 macros (good) or bash (ugly). Are all of the tests really needed? A lot of effort is focused on correct optimization flags, ASM usage etc.
  • aclocal.m4
This file is already written by someone (whereas it should be generated by aclocal). It contains macro definitions that are used by autoconf to create configure script.
  • allegro.m4
Contains macro definitions for detecting the presence of Allegro libraries when compiling programs. Very complex and I don't understand it all.
  • makefile.in
Some automake template, very long, also contains bash code.
  • allegro-config script and AM_PATH_ALLEGRO macro
Files used for developers that use autotools - very complex and hard to understand

Proposed state

The proposed layout

  • configure.ac (former configure.in)
Simplified configure.in, I would like to make that file as easy to understand and maintain as possible while keeping the purpose -- to be able to check and customize lot of things (that autoconf can do, no more bash scripts)
  • acinclude.m4 (former aclocal.m4)
This file should be OK, maybe just some smaller simplifications and either leaving it in the build root or putting it into m4 subdirectory...
  • Makefile.am (former makefile.in)
Usage of multiple makefiles (for library, for examples, for dcumentation...)
  • usage of pkg-config instead of allegro-config and AM_PATH_ALLEGRO macro

Info needed

Maybe all of this is not possible, so one has to ask autotools and pkg-config guys.

But these info about allegro are needed:

  1. What is the mechanism of multiplatform compilation in English that one can understand? What needs to be done with the source when compiling for *nixes, Windows(MinGW), optionally Mac, BeOS, BSD? There are also some sources listed in makefile.lst
  2. What can be dropped from the autotools support from the table below?
Thing to drop Reason Safe to drop?
debug with dmalloc obsolete due to Valgrind  ?
debug with Fortify obsolete due to Valgrind  ?
alsa v5 What is it? Does anybody know since it can be still found somwhere?  ?

Links

Autotools guide at Linux.com
Autoconf manual at GNU.org
How to adapt a project to autotools at freesoftwaremagazine.com