About autoconf

Quoting autoconf project homepage:

Autoconf is an extensible package of m4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of m4 macro calls.

where 'm4' is a 'macro processor'. For your needs as wxCode maintainer, autoconf is an utility which transforms your build/configure.ac file into configure which is a shell script which can be used by users of your components, together with Makefile.in (which is generated by bakefile), to build your component on a LOT of unix-based systems (also win32, using Cygwin).

The documentation for autoconf is available in many formats; you can browse it online here; it's quite big so I suggest you to use it as 'reference manual'...


The 'configure.ac' syntax

^ TOP

As written in the wxCode bakefile guide, you should use wxCode/build/autoconf/configure.ac as 'skeleton'.
You can edit it with your favourite text editor (just be sure that when you process it with autoconf it has UNIX line endings; see below).

Typically, if your component does not use any external library, you don't have to change anything into configure.ac except for the component name and version. However these are generic guidelines to keep in mind when editing configure.ac scripts:


What you need to change in your configure.ac

^ TOP

The default configure.ac file for a wxCode component is quite simple; you can view it online here.

For a simple component, with no external libraries required, you'll probably only need to change:

For more complex components, you'll need to write also configure checks for seamless configuration in the user's system...

Writing configure checks

^ TOP

The configure scripts are used to detect the settings to generate the final makefile. One of the most important check to do is the one for external dependencies. The following are the main ways to perform this kind of checks:

  1. the AC_LINK_IFELSE macro:

        dnl add the external library to the list of libraries which will be used for our test program
        LIBS="-llibtotest $LIBS"
    
        dnl check for the presence of 'libtotest'
        AC_MSG_CHECKING([for the libtotest availability])
        AC_LINK_IFELSE([
                        AC_LANG_PROGRAM([#include <libtotest/header.h>],
                                        [libtotest_object fakeinstance;])
                        ],
                        [LIBTOTEST_PRESENCE=1], [LIBTOTEST_PRESENCE=0])
    
        if test "$LIBTOTEST_PRESENCE" = "1"; then
            AC_MSG_RESULT([found])
        else
            AC_MSG_RESULT([not found !])
        fi
        
  2. if you need to check for the presence of another wxCode component, then you can use the WXCODE_CHECKFOR_COMPONENT:

        dnl check for wxXml2 component
        WXCODE_CHECKFOR_COMPONENT([wxXml2], [wx/xml2.h], [wxxml2],
            [wxXml2Node faketest;], [WXXML2_PRESENCE=1], [WXXML2_PRESENCE=0])
        

    As you can see in the wxCode/build/autoconf/wxcode.m4 file, where this macro is defined, it's a simple 'shortcut' to the AC_LINK_IFELSE macro described above.
  3. if you need to check for a package which contains a '.pc' file, that is, a package that includes a pkg-config metadata file, then you can simply use the PKG_CHECK_MODULES macro. Look in man pkg-config page for more info about it. A typical sample is:

        dnl check for libtotest; if it cannot be found or it's too old, PKG_CHECK_MODULES
        dnl macro will automatically print an error message and exit the configure script.
        PKG_CHECK_MODULES([LIBXML2], [libxml-2.0 >= 2.6.19])
    
        dnl now add the variables LIBXML2_LIBS and LIBXML2_CFLAGS
        dnl (which have been created by PKG_CHECK_MODULES macro)
        dnl to our global LIBS and CFLAGS variables.
        LIBS="$LIBXML2_LIBS $LIBS"
        CFLAGS="$LIBXML2_CFLAGS $CFLAGS"
        


Processing 'configure.ac' to generate configure

^ TOP

Before trying to process your configure.ac, be sure that:

  1. you ran bakefile_gen in your component's build folder;
  2. your configure.ac, config.sub, config.sub, Makefile.in have Unix line endings and that you have permission to execute them (you can use the dos2unix and chmod tools for this);
  3. you have Bakefile > 0.1.9.1 installed on your Unix system (bakefile 0.1.9.1 does not work well with autoconf due to a little bug);
  4. check that you have an automake version >= 1.9.6 (with the command aclocal --version) since aclocal 1.9.5 is affected by a bug in m4_include statements which prevents it from working correctly.

    You can install the latest automake package from ftp://sources.redhat.com/pub/automake/: untar the downloaded package and launch the usual ./configure && make && make install command.

If all points above have been checked, then you can run the script:

./acregen.sh

This little script will run aclocal (a little utility which collects all macro definitions used by your configure.ac), autoconf and then will move the configure script in the root folder of your component.

The "configure" script can then be used by your component's users in this way:

./configure && make && make install

to build and install your component.