# Anjuta build tutorial

v0.2
2004 Olivier Pinçon
2008 Sébastien Granjoux

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the GNU Free Documentation License from the Free Software Foundation by visiting their Web site or by writing to: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any GNOME documentation, and those trademarks are made aware to the members of the GNOME Documentation Project, the names have been printed in caps or initial caps.

This is version 0.2 of Anjuta build tutorial

## Introduction

If you come from the Windows world, when you first launched Anjuta, you can told yourself : "Hey, that looks like MS Visual C++, as I know it pretty well, understanding Anjuta will be a piece of cake.". Anjuta looks like Microsoft Visual Studio or Borland's C++ Builder. but it has some significative differences essentially in its build system.

If you are starting programming directly on GNU/Linux, you have probably already heard of the Autotools. They are a major and probably a bit intimidating part of the development environment.

The goal of Anjuta is to make it easier to use the already existing development tools. Anjuta main build system uses the standard Linux build system: Autotools. This tutorial is an updated version of the Anjuta advanced tutorial from Olivier Pinçon. It explains how the build system is working without Anjuta and how to use it within Anjuta. It assumes that you have only a basic understanding of C or C++ and have been written using Anjuta 2.6 (September 2008).

If you find errors, need more explanations or have any idea for improvements on this tutorial or Anjuta in general, you can:

- Fill a bug in Anjuta bugzilla database.

- Send a message to Anjuta developer mailing list anjuta-devel@lists.sourceforge.net

- Join Anjuta IRC channel #anjuta on irc.gnome.org

## Building a project

This chapter explains how to build a program starting from the most basic tool: the compiler. This order is important to understand how is it working because each tool adds a new layer on top of the previous ones.

### Using GCC

Here is a typical command to generate an executable from C source files using GCC:

    $gcc -g -Wall -I/usr/include/libxml2/libxml -lxml2 main.c aux.c -o tut_prog

This command tells GCC to compile the source files main.c and aux.c, and produce a binary called 'tut_prog' (this stands for 'tutorial program'). The various switches have the following meaning :

-g

  tells GCC to include debug information into the binary.

-Wall

  Warning all : print every warning. This switch is used by the C compiler only.

-Idir dir

  Look for included header files (like in #include <myheader.h>) in directory dir. This switch is used by the C preprocessor only.

-llib lib

  Link to library lib; here libxml2, used by the linker.

In fact, GCC does not do the compilation itself. It gets all arguments from the user and calls other programs passing them the needed arguments with some default one to do the four stages involved in the compilation.

GCC compilation stage

#### Preprocessor

Each C source file goes through the preprocessor, named cpp. In this stage, all include files and macros are expanded to get preprocessed C source code. The resulting file .i is rarely generated but it could be interesting to see how complex macros are expanded. You can do this by calling cpp directly or using the `-E` switch of GCC. The later option is better as it allows to run the preprocessor with all default options.

#### Compiler

In this stage each file is compiled into assembler code. The compiler depends on the language of the source file, C here. It is a complex program because there is not a one to one correspondence between C instructions and assembler instructions. By example, requesting the fastest or the smallest program will generate different sequences of assembler instructions. The assembler is the language of your computer, the most common one is called x86. The output is a, human readable, assembler source file ending with '.s'. Like the preprocessor output, the assembler code is not normally written on the hard disk. You can stop the compilation at this stage to look at it by running GCC with the `-S` switch.

#### Assembler

In this stage each file is assembled: the assembler code is transformed to an object file with .o extension. It is much easier than the compilation as each assembler instruction corresponds to an unique code. The object file contains additional information for debugging or linking the program. The object file is a binary format, called ELF on recent Linux machine, you need to use special program to look in it like objdump. It is possible to write directly assembler code and assemble it using the assembler ,as, or GCC if your source file has a .s extension. These object files are commonly written on your hard disk because it depends only of theirs corresponding C source file (with all files included). If you modify only one source file, you need to regenerate only the corresponding object file. You can stop at this stage, without linking by using `-c` switch with GCC.

#### Linker

This stage is used to combine all the object files and libraries into one executable file. The result is a binary file in a format close to the object file, on Linux it is even the same format.

### Using make

When a program is composed of lots of sources files, it is much faster to keep the object files and recompile each source files only when needed. This can be automated using make. It executes a program written in a makefile, normally named `Makefile`. A sample makefile for the previous tutorial program could be :

A simple Makefile file

    CC=gcc 	# the C compiler is gcc
    CFLAGS=-g -Wall -I/usr/include/libxml2
    LIBS=-lxml2

    tut_prog: main.o aux.o   # what we need to have 'tut_prog'...
    	$(CC) $(LIBS) main.o aux.o -o tut_prog # ...and how to get it from the ingredients.

    main.o: main.c
    	$(CC) -c $(CFLAGS) main.c

    aux.o: aux.c
    	$(CC) -c $(CFLAGS) aux.c

Makefiles are a kind of program but instead of writing what should be done sequentially to get the result, you define some rules and make uses these rules in whatever order to achieve the result.

#### Variables

Like in any programming language, you can define variables in a make file. All variables contains a string or a list of strings separated by whitespace. A variable is defined using the following syntax: name=value. You can get its value by writing $(name) or ${name}. In the sample above, three variables are defined CC, CFLAGS and LIBS.

Variables can be redefined when calling make in the command line or using values from environment. Moreover make includes some default rules using predefined variables. Here is a list of the most common ones:

`CC`

  Program for compiling C programs, default 'cc'

`CXX`

  Program for compiling C++ programs, default 'g++'

`CPP`

  Program for running C preprocessor, default '$(CC) -E'

`FC`

  Program for running Fortran compiler, default 'f77'

`RM`

  Command to remove a file, default 'rm -f'

`CFLAGS`

  Extra flags for the C compiler

`CXXFLAGS`

  Extra flags for the C++ compiler

`CPPFLAGS`

  Extra flags for the C++ compiler

`CXXFLAGS`

  Extra flags for the C preprocessor

`FFLAGS`

  Extra flags for the Fortran compiler

`LDFLAGS`

  Extra flags for the linker

#### Rules

The basic syntax for make rules is:

    target: prerequisites
    	commands
    	…

The target and the prerequisites are normally files but they could be actions. The rule is interpreted as in order to make the target or update it if it is older than its prerequisites, you need to make all prerequisites and then run all commands.

make starts with the first target of the makefile or the one given in the command line and looks for a rule. If this rules has no prerequisites, the associated commands are run and that's all. Else before running the commands, for each prerequisite, make looks for a rule having it as target and repeats the same process.

In the sample above, if you run `make` or `make tut_prog`. make does the following:

    Search a rule with tut_prog as target
    Found with prerequisites main.o aux.o
    	Search a rule with main.o as target
    	Found with prequisite main.c
    		Search a rule with main.c as target
    		Not found (main.c is a source file)
    	If main.o does not exist or is older than main.c
    		Compile main.c, do not link (-c switch)
    	Search a rule with aux.o as target
    	Found with prequisite aux.c
    		Search a rule with aux.c as target
    		Not found (aux.c is a source file)
    	If aux.o does not exist or is older than aux.c
    		Compile aux.c, do not link (-c switch)
    If tut_prog is older than main.o or aux.o
    	Link main.o, aux.o and libxml2

Like for variables, several target names are commonly defined:

all

  Do everything

check

  Perform some self test after building the program

clean

  Delete all files created by make

distclean

  Delete more files than clean, could delete the Makefile itself

dist

  Create a distribution package, a compressed tarball by example

install

  Install target created by make, need to be run as root to install in system directories

uninstall

  Remove files installed by make

Programs compiled from sources are installed by default in `/usr/local`. If you want to install (or uninstall) a program in such system directory, you normally need to log as root using `su` or `sudo` before running `make install`.

### Using Autotools

If you want to build your program on another system, using make only could be quite difficult. The C compiler could be different. Some common C functions could be missing, have another name, declared in a different header and so on. This can be handled by enabling difference piece of code in your sources using preprocessor directive #if, #ifdef and others. But the user will have to define himself all these tuning which is not easy as there is a lots of systems with a lots of variations.

Free softwares are mainly distributed as sources. It is crucial to be able to recompile them on various system without much technical knowledge. Autotools is designed to solve this and you probably have already use it using the magic combination `"./configure; make; make install"`. You may have noticed that many files are involved in this build process; globally all that stuff seems very complicated. So what's happening when you compile such software ?

#### Input files

An Autotools project comes at least with a configure script, named `configure`, and a makefile template named `Makefile.in`. There is normally, one `Makefile.in` in each directory of the project. There are several other files used by an Autotools project but they are not stricly necessary or are generated automatically.

If you look inside these files, you will see that they are quite complex. Do not worry, these files are generated by Autotools from other templates easier to write as explained in . For the moment, we do not care, we consider these files exist as it is the case when you get a source package.

#### Configure

In fact, you don't need Autotools to build an autotools package, configure is a shell script running on the most basic shell: `sh`. It probes your system checking each characteristic and writes makefiles from the templates.

In order to build a project using a library, you need more information about it, so additional files. For a library used in a C program, you need the corresponding header files. This has to be installed on your system and is typically found in a so called development package. By example for the library libxml2, there are two packages:

- `libxml2` necessary to run a program using it and installed automatically as a dependency of such program.

- `libxml2-devel` necessary to build a program using it. If you don't have it configure will display an error message.

Configure process

configure creates all files in the directory where it is called. This directory is the build directory. If you run it from the source directory, using `./configure`, the build directory will be the same.

configure accepts several options in the command line. They are used to install the files in different directories, to disable some parts of the project in order to get a smaller executable or if you haven't one needed library or force a value for some make variable (see ). You can get a list of them by running `configure --help`. Here is a list of the most common ones:

--enable-maintainer-mode

  Add extra rules useful when modifying the project source code

--help

  List all available options

--host host

  Compile to run on another system (cross compilation)

--prefix dir

  Select the root directory for installing the project, default /usr/local

configure generates a few additional files which are less important. `config.log` is a log file useful when something goes wrong to get more details. `config.status` is another shell script, it can be run to restore the current configuration. `config.h` is a header file generated like `Makefile` from a template `config.h.in` if it exists.

#### make

The makefiles generated by configure are quite complex but are standard makefiles. They define all standard targets needed by GNU standard.

- `make` or `make all` builds the program.

- `make install` installs the program.

- `make distclean` removes all files generated by configure, to let the project in the state it was when unpacking the distribution package.

### Using Anjuta

Now, we will see the Anjuta interface allowing you to run all these commands without using the command line.

#### Configure

As Anjuta is using Autotools, the first step is similar, you need to run configure. Select Build Configure Project…, to get the following dialog:

Configure dialog

The Regenerate project checkbox will not be described now as it is related to project creation (see in ).

The Configuration field is an user name used to reference this particular configuration to switch between different ones later. For Anjuta each configuration corresponds to one build directory and a set of configure options. Anjuta already provides some default configurations that you can select here.

It is recommended to use the Debug configuration for debugging. It will compile your program with all optimizations disabled. When optimizations are enabled, some variables and functions are removed, you will not be able to see them with the debugger. Moreover some lines in your source code are re-ordered, so some steps will go backward.

The Build Directory field allow to select the directory used to build the project. It must be different for each configuration.

If you build the project in the source directory (leaving the Build Directory field empty), you cannot create a new configuration. It is a limitation of Autotools. You need to select Build Remove Configuration that will run `make distclean` in the source directory first.

The Configure Options field allow passing different options to the configure script.

Clicking on Execute will run the configure script. All the output will appears in the message view of Anjuta. If the script runs without error, it will enable all other entries in the Build menu.

#### Menu items

The build operations in Anjuta, rely on make only like Autotools. It is working for non Autotools project too. The compile command is even working with only a C source file because make has some builtin rules to compile them. Here is the correspondence between the Anjuta menu item and make commands.

Build Compile

  make current_file

Build Build

  cd `current_file_directory`; make

Build Build Project

  cd `project_directory`; make

Build Build Tarball

  cd `project_directory`; make dist

Build Install

  cd `current_file_directory`; make install

Build Install Project

  cd `project_directory`; make install

Build Clean

  cd `current_file_directory`; make clean

Build Clean Project

  cd `project_directory`; make clean

Build Remove Configuration

  cd `project_directory`; make distclean

The last menu entry not described above ,Build Select Configuration, allows you to switch easily between different configurations and so between different build directories.

#### Options

A few common build options are available in the preferences page that you can get by selecting Edit Preferences Build autotools .

Build preferences

## Creating a project

This chapter explains how to create a new project. Like the previous, it starts with Autotools before looking at Anjuta.

### Using Autotools

In the first chapter, we have not really used the Autotools. It is not need to compile a project from the sources. But all files in the build process are not written by hand but generated from templates using Autotools.

Autotools is composed of several tools: `aclocal`, `autoconf`, `automake` and other that we will not see here, belonging to two packages: Automake and Autoconf.

- Autoconf is used to generate the configure script, from a template named `configure.ac`. The configure script will check all characteristics of the host system and generate the makefiles from Makefile.in templates.

- Automake is used to generate complete Makefile.in templates, following GNU standards from very simple Makefile.am templates.

Autotools process

Now let's see a minimal example to start grasping the relationships between the various files.

#### Write sources

1. Create an empty directory called `tut_prog` and enter in it.

2. In this new directory, create a new file named `main.c` containing:

main.c:

    #include <stdio.h>

    int main()
    {
    	printf("Hello world!\n");
    	return 0;
    }

#### Run Autoconf

1. Write the following in a file named `configure.ac`:

minimal configure.ac:

    AC_INIT([Tutorial Program], 1.0)
    AM_INIT_AUTOMAKE
    AC_PROG_CC
    AC_CONFIG_FILES(Makefile)
    AC_OUTPUT

The configure template script could be named `configure.in`. It is the name used in older version (before 2001) of Autoconf. Nevertheless, it is recommended to use `configure.ac` because the `.in` extension is already used by files processed by configure and generated by Automake: `Makefile.in` and autoheader: `config.h.in`.

AC_INIT, AM_INIT_AUTOMAKE, etc... are M4 macros. M4 is a macro expanding software used by Autotools; we don't need to know about it. When Autoconf will process this configure.in, the macros will be expanded and we will get a fresh huge configure script.

AC_INIT

  Is the first mandatory macro. We need to indicate the name of the project and its version.

AM_INIT_AUTOMAKE

  Initialize environment for Automake. It is needed in all projects using Automake.

AC_PROG_CC

  Determine the C compiler to use.

AC_CONFIG_FILES

  Create each file by copying the corresponding template file (with .in extension) and substituting the output variable values.

AC_OUTPUT

  Marks the end of the configure template.

The use of some macros has changed between different versions of Autoconf:

- The package name and version was defined as arguments of AM_INIT_AUTOMAKE instead of AC_INIT.

- AC_OUTPUT was getting the list of generated files instead of using the additional macro AC_CONFIG_FILES.

Autoconf only knows its own macros but read additional ones in a file named `aclocal.m4`. These macros are used to extend Autoconf, it includes Automake macro (starting with AM_) and other third party macros. For instance, if you develop a library called foo, you might want to write an AC_CHECK_FOR_FOO macro so that developers using your library can check for its presence using Autoconf.

aclocal scans `configure.ac` and create an `aclocal.m4` file which contains the macros mentioned in `configure.ac`. aclocal is part of the Automake package and search by default in Automake macros and in a system path typically `/usr/share/aclocal`.

1. Launch `aclocal`. It will create a new file named `aclocal.m4` in the current directory.

2. Launch `autoconf`. It will create the configure script `configure`.

On my system, I actually get an extra directory called `autom4te.cache`. That is for Autoconf internal purposes. You do not need to care about it.

#### Run Automake

1. Write the following in a file named `Makefile.am`:

minimal Makefile.am:

    bin_PROGRAMS = tut_prog
    tut_prog_SOURCES = main.c

In Makefile.am are the very essential data needed to build the project: the target program, called tut_prog, will be put in a $prefix/bin/ directory; to build it we need main.c. Note that we don't specify how that will be built: Automake will figure it out. We haven't even mentioned the compiler in this pre-makefile.

Makefile.am will be processed by Automake; the result will be a Makefile.in. This Makefile.in is close to being a real makefile, but it contains variable names which will be replaced when the configure script will run, resulting in a real makefile (called Makefile). For instance, `configure` will write in the final Makefile what compiler to use (it is the compiler it found using the AC_PROG_CC macro).

1. Run the command `automake --add-missing --foreign`. It will create a new file named `Makefile.in` as expected. Moreover, due to the switch --add-missing you get a few links to scripts necessary for building the project: `depcomp`, `install.sh` and `missing`. The other option --foreign tells to Automake that you don't want to follow GNU standard and you don't need mandatory documentation files: `INSTALL`, `NEWS`, `README`, `AUTHORS`, `ChangeLog` and `COPYING`. I have used it here to keep the number of created file to a minimum but else it is a good idea to provide these files, you can start with empty files.

#### Build project

1. Run now the new configure script: `./configure`. You get the following output and it create the makefile for your program.

       checking for a BSD-compatible install... /usr/bin/install -c
       checking whether build environment is sane... yes
       checking for a thread-safe mkdir -p... /bin/mkdir -p
       checking for gawk... gawk
       checking whether make sets $(MAKE)... yes
       checking for gcc... gcc
       checking for C compiler default output file name... a.out
       checking whether the C compiler works... yes
       checking whether we are cross compiling... no
       checking for suffix of executables...
       checking for suffix of object files... o
       checking whether we are using the GNU C compiler... yes
       checking whether gcc accepts -g... yes
       checking for gcc option to accept ISO C89... none needed
       checking for style of include used by make... GNU
       checking dependency style of gcc... gcc3
       configure: creating ./config.status
       config.status: creating Makefile
       config.status: executing depfiles commands

2. Run now `make`, to build your program. You get the following output and a new tut_prog executable

       gcc -DPACKAGE_NAME=\"Tutorial\ Program\" -DPACKAGE_TARNAME=\"tutorial-program\"   \
               -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"Tutorial\ Program\ 1.0\"     \
               -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"tutorial-program\" -DVERSION=\"1.0\" \
               -I.     -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
       main.c: In function ‘main’:
       main.c:5: warning: return type of ‘main’ is not ‘int’
       mv -f .deps/main.Tpo .deps/main.Po
       gcc  -g -O2   -o tut_prog main.o

3. Now, if you can write in `/usr/local/bin`, run `make install` to install your program. Else you need to log as root before or use sudo and run `sudo make install`. You should get.

       make[1]: Entering directory `/home/seb/Projects/Tutorial'
       test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin"
         /usr/bin/install -c 'tut_prog' '/usr/local/bin/tut_prog'
       make[1]: Nothing to be done for `install-data-am'.
       make[1]: Leaving directory `/home/seb/Projects/Tutorial'

   Then, if `/user/local/bin` is in your path, you can run your program from everywhere.

#### Clean project

1. The program is installed, so you can clean the build directory running `make clean`. It removes all object files and the program but not the makefiles.

       test -z "tut_prog" || rm -f tut_prog
       rm -f *.o

   You can still run the program installed in `/user/local/bin`.

2. To remove the installed program, run `make uninstall`. Like for the installation, you need to use have the writing right in the directory or use su or sudo.

       rm -f '/usr/local/bin/tut_prog'

#### Generate project

Running `aclocal`, `automake` and `autoconf` one by one is fine for a tutorial to understand exactly what's happen. But, for a real work, it's a bit tedious especially because there are other tools those could be needed like `autoheader`, `autopoint` or `libtoolize`. After creating the project, the makefiles generated by configure should take care of regenerating `configure` and all `Makefile.in`. Anyway, this lets a room for improvement and there are even two responses to this:

autoreconf

  It is another tool part of the Autoconf package which is running all scripts in the right order. To start a new project, you can just run `autoreconf --install` and it will call all necessary commands.

autogen.sh

  It is a script not part of Autotools, that it doing the same thing. There is one named `gnome-autogen.sh` which comes with GNOME common development package but other project can write their own ones.

### Using Anjuta

Creating a project with Anjuta need just a few clicks but then we will take a look at the created files.

#### Create a new project

1. Click on File New Project. The new project assistant appears.

2. Click on Forward. The project selection page appears:

   Project selection page

3. Select Generic (minimal) project in the C page.

4. Click on Forward.

   Project basic information page

   Change Project Name to `tutprog`, the project name should contains only alpha numeric characters or underscore. Fill the remaining field.

5. Click on Forward.

   Project options page

   Click on Destination and create a new directory named tutprog for your new project. You need to avoid space in the directory name. Then, keep all other options to their default value to get a minimal project.

6. Click on Forward.

   Project summary page

   This is the final page of the assistant, check that everything is right.

7. Click on Forward. Anjuta will create all needed files and directories, in the message window, you will see the following:

   Project creation messages

   Then, autogen.sh is called and run the configure script. Finally Anjuta open the new project. You can directly build the project, as the main source contains a few lines of C and configure has been run.

#### Looking at configure.ac

Anjuta minimal configure.ac:

    dnl Process this file with autoconf to produce a configure script.
    dnl Created by Anjuta application wizard.

    AC_INIT(tutprog, 0.1)

    AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)
    AC_CONFIG_HEADERS([config.h])
    AM_MAINTAINER_MODE

    AC_PROG_CC

    AC_OUTPUT([
    Makefile
    ])

It is still quite simple with a bit more macros. Let's look at all unknown ones:

dnl

  It is not a macros, just the marker to start a comment in M4, the language used to write `configure.ac`. It is like '#' is scripts or '//' in C++.

AM_INIT_AUTOMAKE

  The AC_INIT macro uses the new form with package and version but AM_INIT_AUTOMAKE keeps the old one. It is not needed anymore.

AC_CONFIG_HEADERS

  This tells Autoconf to pass all defines in a file named `config.h` instead of using several -Dxxxx flags on the command line (see ). It is easier when there are lots of them. A file named `config.h.in` is created automatically from the `configure.ac` using autoheader. Then `config.h` is created automatically like makefiles by configure. So it is painless for the developer.

AM_MAINTAINER_MODE

  By default the makefiles created by Automake have rules to rerun Automake or Autoconf when needed: if `configure.ac` or `Makefile.am` are modified. By using this macro, you disable this feature. So `configure.ac` and all `Makefile.am` will never be erased, even if you get a problem with the date of some files which could be better for an user, someone compiling the project without modifying it. A developer, someone modifying the project, needs these rules and has to run configure with --enable-maintainer-mode to keep those. The real interest of this macro is debatable.

AC_OUTPUT

  This is the old form of the AC_OUTPUT, where you specify all output files instead of using AC_CONFIG_FILES.

#### Looking at Makefile.am

Anjuta minimal Makefile.am:

    ## Process this file with automake to produce Makefile.in
    ## Created by Anjuta

    AM_CPPFLAGS = \
            -DPACKAGE_DATA_DIR=\""$(datadir)"\"

    AM_CFLAGS =\
             -Wall\
             -g

    bin_PROGRAMS = tutprog

    tutprog_SOURCES = \
            main.c

    tutprog_LDFLAGS =

    tutprog_LDADD =

Not much things in the `Makefile.am` neither:

AM_CPPFLAGS

  It is used to give additional flags to the C preprocessor. Here it defines an additional PACKAGE_DATA_DIR constant set by configure

AM_CFLAGS

  It defines some additional flags for the C compiler: all warning and add debugging information that we have already seen at the beginning of this tutorial (see )

tutprog_LDFLAGS

  It adds a places where you can put additional linker options for the tutprog program.

tutprog_LDADD

  It adds a places where you can put additional libraries for the tutprog program.

## Adding a library

This chapter explains how to add a new library to a project. It starts with Autotools before looking at Anjuta.

### Using Autotools

Adding a new library in a autotools project could be more or less easy depending on how the library is packaged. To take an example, imagine that we want to read an xml file using libxml2 (see its homepage at www.xmlsoft.org)

1. Open the old tutorial project and replace `main.c` by the following.

   main.c using libxml2:

       #include <libxml/parser.h>
       #include <stdio.h>

       int main()
       {
       	xmlDocPtr doc;
       	doc = xmlParseFile ("testfile.xml");

       	if (doc == NULL) {
       		printf ("Document not parsed successfully. \n");
       		return -1;
       	}
       	else {
       		printf ("Document parsed successfully.\n");
       		xmlFreeDoc(doc);
       		return 0;
       	}
       }

Our goal is now to compile it and make it work correctly. For that purpose, we must tell GCC two things: where to find libxml/parser.h (that is to say, give GCC the right include path) and what library (i.e. shared object) it should link our project against. There are several ways to do that, I will start with the easiest.

#### With pkg-config

pkg-config is tools for developers providing a unified interface for querying installed libraries with their version and all options needed to compile and link it. It comes with an Autoconf macro named PKG_CHECK_MODULES allowing to check the existence of the library and set all necessary flags.

1. Add the following line in `configure.ac`.

       PKG_CHECK_MODULES(XML, libxml-2.0 >= 2.4)

   This macro will check the existence of libxml2 with a version higher or equal to 2.4 and create 2 variable XML_CFLAGS and XML_LIBS containing respectively, the flags for the C compiler and the linker. `XML` is an user defined name. `libxml-2.0` is the name of the library. You can run `pkg-config --list-all` to get a list of all installed libraries.

2. Add the following lines in `Makefile.am`.

       tut_prog_CPPFLAGS = $(XML_CFLAGS)
       tut_prog_LDFLAGS= $(XML_LIBS)

   This will use the options found by configure when the macro PKG_CHECK_MODULES is executed for compiling your program.

3. That's all. You can run `make` again.

       cd . && /bin/sh /home/seb2008.1/Projects/tutprog/missing --run aclocal-1.10
       cd . && /bin/sh /home/seb2008.1/Projects/tutprog/missing --run automake-1.10 --foreign
       cd . && /bin/sh /home/seb2008.1/Projects/tutprog/missing --run autoconf
       /bin/sh ./config.status --recheck
       running CONFIG_SHELL=/bin/sh /bin/sh ./configure  --enable-maintainer-mode  --no-create --no-recursion
       checking for a BSD-compatible install... /usr/bin/install -c
       checking whether build environment is sane... yes
       checking for a thread-safe mkdir -p... /bin/mkdir -p
       checking for gawk... gawk
       checking whether make sets $(MAKE)... yes
       checking whether to enable maintainer-specific portions of Makefiles... yes
       checking for style of include used by make... GNU
       checking for gcc... gcc
       checking for C compiler default output file name... a.out
       checking whether the C compiler works... yes
       checking whether we are cross compiling... no
       checking for suffix of executables...
       checking for suffix of object files... o
       checking whether we are using the GNU C compiler... yes
       checking whether gcc accepts -g... yes
       checking for gcc option to accept ISO C89... none needed
       checking dependency style of gcc... gcc3
       checking for library containing strerror... none required
       checking for gcc... (cached) gcc
       checking whether we are using the GNU C compiler... (cached) yes
       checking whether gcc accepts -g... (cached) yes
       checking for gcc option to accept ISO C89... (cached) none needed
       checking dependency style of gcc... (cached) gcc3
       checking for gcc... (cached) gcc
       checking whether we are using the GNU C compiler... (cached) yes
       checking whether gcc accepts -g... (cached) yes
       checking for gcc option to accept ISO C89... (cached) none needed
       checking dependency style of gcc... (cached) gcc3
       checking how to run the C preprocessor... gcc -E
       checking for grep that handles long lines and -e... /bin/grep
       checking for egrep... /bin/grep -E
       checking for ANSI C header files... yes
       checking for pkg-config... /usr/bin/pkg-config
       checking pkg-config is at least version 0.9.0... yes
       checking for XML... yes
       configure: creating ./config.status
        /bin/sh ./config.status
       config.status: creating Makefile
       config.status: creating config.h
       config.status: config.h is unchanged
       config.status: executing depfiles commands
       cd . && /bin/sh /home/seb2008.1/Projects/tutprog/missing --run autoheader
       rm -f stamp-h1
       touch config.h.in
       cd . && /bin/sh ./config.status config.h
       config.status: creating config.h
       config.status: config.h is unchanged
       make  all-am
       make[1]: Entering directory `/home/seb/Projects/tutprog'
       gcc -DHAVE_CONFIG_H -I.  -DPACKAGE_DATA_DIR=\""/usr/local/share"\" -I/usr/include/libxml2  \
               -Wall -g -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
       mv -f .deps/main.Tpo .deps/main.Po
       gcc -Wall -g -g -O2   -o tutprog main.o -lxml2
       make[1]: Leaving directory `/home/seb/Projects/tutprog'

   There is no need to rerun Autoconf or Automake because the Makefile generated by it already contains some rules to do it.

When installed, each library supporting pkg-config copy a small text file, with .pc extension, in a system directory; normally `/usr/lib/pkgconfig`. If you install a library from source it will be by default in `/usr/local/lib/pkgconfig`. You can ask pkg-config to search in this directory too, by defining the environment variable `PKG_CONFIG_PATH=/usr/local/lib/pkgconfig`.

#### With an Autoconf macro

If the library does not support pkg-config: it does not appear in the list returned by `pkg-config --list-all`. You need a Autoconf macro:

- Check if the library author shipped a M4 macro, and use it if present. It is a text file named like the library with a .m4 extension often installed in `/usr/share/aclocal`.

- If your library is a basic one, it might be checked by the standard Autoconf macros (see the list here).

- Perhaps the M4 macro you need has already be programmed by someone else. Look at the contributions here.

- If all that fail, go deeper in M4, make your own macro, and donate it to the library's author!

When, you have this macro, you can copy it in `/usr/share/aclocal`, so aclocal will find it. Then, you just need to look in the macro file to see how to use it. libxml2 installs a macro named AM_PATH_XML2 which is in `/usr/share/aclocal/libxml.m4`.

1. Add the following line in `configure.ac`.

       AM_PATH_XML2(2.4.0)

   This macro will check the existence of the library with a version higher or equal to 2.4 and create 2 variable XML_CPPFLAGS and XML_LIBS containing respectively, the flags for the C compiler and the linker. You get these information from the comments in the macro file.

2. Add the following lines in `Makefile.am`.

       tut_prog_CPPFLAGS = $(XML_CPPFLAGS)
       tut_prog_LDFLAGS= $(XML_LIBS)

   This will use the options found by configure for compiling your program. Note that the macro defined XML_CPPFLAGS instead of XML_CFLAGS with pkg-config. Using CPPFLAGS makes more sense, because these flags are used by the C preprocessor, most of the time only to setup the path of the include files.

3. That's all. You can run `make` again. The generated `Makefile` is almost the same.

#### With hardcoded library path

It is the approach one could naturally have: let's give GCC the stuff it needs directly ! On my system, `libxml/parser.h` is in `/usr/include/libxml2`, and the shared object is 'libxml.so', located in `/usr/lib`. (I will assume it's all the same for you).

1. Add the following lines in `Makefile.am`.

       tut_prog_CPPFLAGS = -I /usr/include/libxml2
       tut_prog_LDFLAGS= -lxml2

   There is no need to change `configure.ac` because you don't check anything and just assume that all host system will have the right library in the same place than you.

2. You can run `make` and it should work if you have the same system than me.

        cd . && /bin/sh /home/seb2008.1/Projects/tutprog/missing --run automake-1.10 --foreign  Makefile
        cd . && /bin/sh ./config.status Makefile depfiles
       config.status: creating Makefile
       config.status: executing depfiles commands
       make  all-am
       make[1]: Entering directory `/home/seb/Projects/tutprog'
       gcc -DHAVE_CONFIG_H -I.  -DPACKAGE_DATA_DIR=\""/usr/local/share"\" -I /usr/include/libxml2  \
           -Wall -g -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
       mv -f .deps/main.Tpo .deps/main.Po
       gcc -Wall -g -g -O2   -o tutprog main.o -lxml2
       make[1]: Leaving directory `/home/seb/Projects/tutprog'

I have described this here to show that it is possible to do simple thing using Autotools. But this approach has several drawbacks:

- It is not portable to various linuxes: perhaps on other distribution the include path is different.

- If the next versions of libxml have different paths, or different needed libraries, we will need to update the project.

- We don't test whether the system of the packager/user has the library.

- We cannot check the version of the libxml2 we use.

### Using Anjuta

With Anjuta adding a library supporting pkg-config can be almost done without the keyboard.

#### With pkg-config

1. Open the file `main.c` of the Anjuta project created in the previous chapter. Replace it with the following text:

   main.c using libxml2:

       #include <libxml/parser.h>
       #include <stdio.h>

       int main()
       {
       	xmlDocPtr doc;
       	doc = xmlParseFile ("testfile.xml");

       	if (doc == NULL) {
       		printf ("Document not parsed successfully. \n");
       		return -1;
       	}
       	else {
       		printf ("Document parsed successfully.\n");
       		xmlFreeDoc(doc);
       		return 0;
       	}
       }

2. Select Project Properties Packages, to get the package properties dialog.

3. Click on Add module button and Enter a name in the Module/Package column, "XML" by example.

4. Click on Add Package button that should be enabled now. You get the a dialog where you can select the library that you want to use. This dialog list all libraries supporting pkg-config. Select `libxml-2.0`. Then click on Add button.

5. The package properties dialog should look like the following:

   Project package properties dialog

   The module XML contains one library named libxml-2.0. You can define a minimum version required by clicking in the version column and writing `>= 2.4`. All this operation add the necessary lines in the file `configure.ac`.

6. Close the dialog and select Project Refresh. This should not be needed but is necessary with the current version of Anjuta. This bug has already been reported (#541694) and will be fixed soon

7. In the project view, select the project target tutprog and click on right button to get a context menu and select Properties. You will get the target properties dialog.

8. This dialog will list all modules available in your project, just check the XML module. This will modify the file `Makefile.am` to use the right library.

   Target properties dialog

9. Click on Close and that's all. You can select Build Build to rebuild your project.

#### Without pkg-config

Anjuta has no real support for library not using pkg-config. You need to edit the `configure.ac` directly to add all necessary macros. For passing flags to each target you can select the Advanced button in the target properties dialog.

## Resources

Here are some links to reference documents dealing with Autotools in general and Autoconf and Automake in particular.

English

  - First, you can take a look at the Autoconf, Automake, Libtool, make and M4 manuals.

  - The Autobook explains in details how the Autotools work.

  - Amongst the various GNU development tools you are told about, here are Autoconf and Automake.

  - Here and here are two other tutorials about Autotools.

French

  Here are some slides by a teacher from Ecole Nationale Supérieure des Télecoms about the Autotools.

Japanese

  A tutorial about Autoconf and Automake .

This tutorial uses Autoconf 2.61 (November 2006) and Automake 1.10.1 (January 2008). Some of these documentations uses older versions. the syntaxes could have changed quite a bit. These old syntaxes usually still work and are used in old project. It is useful to know them but it is a bad idea to use them in a new project.