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:

• the AC_INIT macro must be the first macro of the script; you can put only comments before it
• configure.ac files are simple shell scripts where all AC_*/AM_* macros are substituted; so you can use all you can usein bash scripts (see Advanced BASH scripting guide)
• don't use the following syntax:
  
  if [ $MYVAR = "myvalue" ]; then do something; fi
  since the "[ ]" brackets are used to quote M4 strings; use instead:
  
  if [[ $MYVAR = "myvalue" ]]; then do something; fi
• don't place comments inside macros:
  
  AC_MY_MACRO([arg1], # my MISPLACED comment
  [arg2], # another wrong comment )
  just place the comments below or above the macros.

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:

• the AC_INIT line, with your real component name and version
• the WXCODE_OPTIONS line, excluding eventually options which you don't want to support (e.g. --disable-unicode)
• the WXCODE_CHECKS line, with the list of the wxWidgets libraries your program/library needs to link to

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:

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:

to build and install your component.