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

Autotoolset

From Allegro Wiki
Jump to: navigation, search
This article is incomplete and needs some revision or has some pending TODOs. Please help Allegro by editing and finishing it. When the article becomes complete, you may remove this tag.


Merge-arrows.gif
It has been suggested that this article or section be merged with Using Allegro with autoconf/KDevelop. (Discuss)


Contents

Just noticed, apparently, there's also Using Allegro with autoconf/KDevelop... maybe that answers some of the questions at the end of this page, must look later..

An automake manual is here

An autoconf manual here or here for version 2.57

automake, autoconf

I was using custom Makefiles for years, to work around all the shortcomings of autotools (e.g. no portability, and no support for the things mentioned below). But still, for unix, autotools have advanatages, especially if you need lots of compile-time checking of dependencies.

The following is what I've come up with. Hopefully someone can fill in the things I couldn't figure out.

Directory structure

+<font color="#ff0000">myprog</font>
{| class="wikiTable" 
| class="wikiTableRowEven" | -- configure.ac

|-
| class="wikiTableRowOdd" | -- Makefile.am

|-
| class="wikiTableRowEven" | --+src

|}
   |-- here goes all the source files

configure.ac

So far, it looks like this:

myprog/configure.ac:

AC_INIT(<font color="#ff0000">myprog</font>, 1.0)
AC_PREREQ(2.5)
AM_INIT_AUTOMAKE ...
AM_CONFIG_HEADER([config.h])

AC_PROG_CC

AC_OUTPUT([Makefile src/Makefile])

Makefile.am in toplevel dir

Looks like this:

myprog/Makefile.am:

SUBDIRS = src

Makefile.am in src dir

Looks like this:

myprog/src/Makefile.am:

bin_PROGRAMS =  <font color="#ff0000">myprog</font>
<font color="#ff0000">myprog</font>_SOURCES = <font color="#ff0000">myprog1.c</font> <font color="#ff0000">myprog2.c</font>

AM_CFLAGS = -W -Wall -g3

How to compile

Only as developer

First, you run this:

aclocal

If you get any warnings, then probably because of system files with incompatible warnings. Ignore them. It should have created the file aclocal.m4 for you.

Next, run this:

autoheader

It will create config.h.in.

Next, run this:

autoconf

It will create the configure script.

Next, run this:

automake -acf --foreign

It will create Makefile.in, as well as some other files. The -acf is to create all those other files, the --foreign is to not create even more files.

As user

As every unix user will know, you now run:

./configure

To create the Makefile. Run this again everytime you want to change the configuration (./configure --help for options).

make

This will do the actual compilation. Run make again whenever the source code changes, autotools will keep track of all dependencies and re-build exactly what is needed.

Cleaning

You can use make clean make distclean and make maintainer-clean to clean up at various levels. Since not even maintainer-clean truly cleans, I made this to remove all generated files I could find. Simply put it into Makefile.am:

.PHONY: shiny
shiny: maintainer-clean
   -rm -f aclocal.m4 config.h.in configure depcomp install-sh Makefile.in missing src/Makefile.in

And then run make shiny. It should get us back into the initial project state and only leave the files which should e.g. go into CVS/SVN/...

Unsolved things

  • How to link in Allegro, other libs, and automatically check that they are installed, and tell the user to get them if not?

See Using Allegro with autoconf/KDevelop.

  • Custom processing of files. E.g. I generate .h files out of .c files with a script - where do i put that?

You can add custom Makefile rules to Makefile.am in any directory. For an example, see Dealing with built sources.

  • Control debug/release build, and if Allegro is linked static/dynamic. Is there a way to not always have to re-run configure? And then, how to write configure checks for it? Do I need even more files besides the autoconf.ac and the two Makefile.am?

The best way to do this is to run ./configure with the arguments `--enable-debug=full --builddir=debug`. This will put all object and program files in the debug/ directory inside the top project dir. So, you can simply run your normal make steps from inside the debug/ directory. To switch to release mode, run "./configure --builddir=release", and non-debugging release files will be in the release/ dir. You may also set a CFLAGS/CXXFLAGS environment variable when running configure to define custom CFLAGS. For example, `CFLAGS="-g3 -O0" ./configure --enable-debug=full --builddir=debug/`

  • Control other things, e.g. to use OpenGL or network support in the game

Again, Using Allegro with autoconf/KDevelop may be of some use. The best way to find if a project supports autoconf is to find the aclocal.m4 file included with the sources. They normally reside in /usr/share/aclocal.

  • Place the executable in the top dir, and place things like .o files into obj/unix/shared/release, and so on..

You can hack this in with a custom makefile rule to copy the program files out to the desired directory, and the --builddir option may be of use to control object file location.

  • have colorful and clean compiler messages like my own Makefile