# Anjuta Erstellungs-Tutorial

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

Das vorliegende Dokument kann gemäß den Bedingungen der GNU Free Documentation License (GFDL), Version 1.1 oder jeder späteren, von der Free Software Foundation veröffentlichten Version ohne unveränderbare Abschnitte sowie ohne Texte auf dem vorderen und hinteren Buchdeckel kopiert, verteilt und/oder modifiziert werden. Eine Kopie der GNU Free Documentation License der Free Software Forundation finden Sie auf deren Webseite oder schreiben Sie an: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Bei vielen der von Firmen zur Unterscheidung ihrer Produkte und Dienstleistungen verwendeten Namen handelt es sich um Marken. An den Stellen, an denen derartige Namen in einer GNOME-Dokumentation vorkommen und wenn die Mitglieder des GNOME-Dokumentationsprojekts über diese Marken informiert wurden, sind die Namen in Großbuchstaben oder mit großen Anfangsbuchstaben geschrieben.

Dies ist Version 0.2 des Anjuta Erstellungs-Tutorials
Mario Blättermann mario.blaettermann@gmail.com
2018 Mario Blättermann

## Einführung

Falls Sie aus der Windows-Welt kommen und Anjuta zum ersten Mal starten, werden Sie sagen: »He, das sieht aus wie MS Visual C++, das ich sehr gut kenne, also wird die Einarbeitung in Anjuta eine Kleinigkeit.« Anjuta sieht aus wie Microsoft Visual Studio oder Borland's C++ Builder, aber es gibt einige signifikante Unterschiede im Erstellungssystem.

Wenn Sie direkt unter GNU/Linux mit dem Programmieren beginnen, haben Sie wahrscheinlich schon von den Autotools gehört. Diese sind ein grundlegender und wohl auch ein wenig einschüchternder Teil der Entwicklungsumgebung.

Das Ziel von Anjuta ist es, die Verwendung der vorhandenen Entwicklungswerkzeuge zu vereinfachen. Anjutas Haupt-Erstellungssystem nutzt das Standard-Erstellungssystem für Linux, die Autotools. Dieses Tutorial ist eine aktualisierte Version des erweiterten Anjuta-Handbuchs von Olivier Pinçon. Es erklärt, wie das Erstellungssystem ohne Anjuta funktioniert und wie es innerhalb von Anjuta verwendet werden kann. Es setzt Ihrerseits ein Grundverständnis von C oder C++ voraus. Das Handbuch wurde für Anjuta 2.6 (September 2008) geschrieben.

Wenn Sie Fehler finden, weitere Erläuterungen benötigen oder Verbesserungsvorschläge zu diesem Tutorial oder zu Anjuta im Allgemeinen haben, können Sie:

- Einen Fehlerbericht in der Anjuta-Bugzilla-Datenbank einreichen.

- Eine Nachricht an die Mailingliste der Anjuta-Entwickler senden: anjuta-devel@lists.sourceforge.net

- Den IRC-Kanal von Anjuta nutzen: #anjuta on irc.gnome.org

## Erstellung eines Projekts

Dieses Kapitel erklärt, wie ein Programm mit dem grundlegendsten Werkzeug erstellt wird, dem Compiler. Diese Reihenfolge ist wichtig, um zu verstehen, wie es funktioniert, da jedes Werkzeug die vorherigen um eine neue Ebene ergänzt.

### GCC verwenden

Hier ist ein typischer Befehl zum Erstellen einer ausführbaren Datei aus C-Quelldateien mittels GCC:

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

Dieser Befehl weist GCC an, die Quelldateien main.c und aux.c zu kompilieren und eine Binärdatei namens »tut_prog« zu erstellen (dies steht für »Tutorial-Programm«). Die verschiedenen Schalter haben die folgende Bedeutung:

-g

  weist GCC an, Fehlerdiagnoseinformationen in die Binärdatei einzubeziehen.

-Wall

  Warning all : gibt alle Warnungen aus. Dieser Schalter wird nur vom C-Compiler verwendet.

-Idir Ordner

  Schaut nach einzubeziehenden Header-Dateien (wie in #include <myheader.h>) im Ordner Ordner. Dieser Schalter wird nur vom C-Präprozessor verwendet.

-llib Bibliothek

  Link zur Bibliothek; hier libxml2, vom Linker verwendet.

Tatsächlich führt GCC die Kompilierung nicht selbst aus. Es wertet alle Argumente des Benutzers aus und ruft andere Programme auf und übergibt an diese die erforderlichen Argumente zusammen mit diversen Voreinstellungen, um die vier Stufen der Kompilierung zu durchlaufen.

Kompilierungsstufe von GCC

#### Präprozessor

Jede C-Quelldatei durchläuft den C-Präprozessor namens cpp. In dieser Stufe werden alle Include-Dateien und Makros expandiert, um den vorverarbeiteten C-Quellcode zu erhalten. Die resultierende Datei mit der Endung *.i wird selten erzeigt, aber könnte interessant sein, um zu sehen, wie komplexe Makros expandiert werden. Sie können dies mit einem direkten Aufruf von cpp erreichen, indem Sie GCC mit dem Schalter `-E` aufrufen. Die letztere Option ist besser, da sie erlaubt, den Präprozessor ohne jegliche Standardoption laufen zu lassen.

#### 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

In dieser Stufe werden alle Objektdateien und Bibliotheken in einer ausführbaren Datei vereint. Das Ergebnis ist eine Binärdatei in einem der Objektdatei nahestehenden Format, auf Linux-Systemen ist es sogar das gleiche Format.

### Verwendung von 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 :

Eine simple Makefile-Datei

    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.

#### Variablen

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

#### Regeln

Dies ist die grundlegende Syntax von Make-Regeln:

    Ziel: Voraussetzungen
    	Befehle
    	...

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

Wie bei Variablen sind verschiedene Zielnamen bereits definiert:

all

  Alles ausführen

check

  Einige Selbsttests nach dem Erstellen des Programms ausführen

clean

  Alle von make erstellten Dateien löschen

distclean

  Noch mehr Dateien löschen als mit clean, wobei auch die Makefile-Datei selbst gelöscht werden kann

dist

  Ein Distributionspaket erstellen, zum Beispiel einen komprimierten Tarball

install

  Das von make erstellte Ziel installieren, muss als Root ausgeführt werden, um in Systemordnern installieren zu können

uninstall

  Die von make installierten Dateien löschen

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`.

### Verwendung der 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 ?

#### Eingabedateien

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.

Konfigurationsprozess

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:

--help

  Alle verfügbaren Optionen auflisten

--host Rechner

  Compile to run on another system (cross compilation)

--prefix Ordner

  Den Wurzelordner für die Installation des Projekts wählen, Voreinstellung ist /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` oder `make all` erstellt das Programm.

- `make install` installiert das Programm.

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

### Verwendung von 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.

#### Menüeinträge

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.

#### Optionen

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.

### Verwendung der 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.

### Verwendung von 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])

    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.

AC_OUTPUT

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

#### Ein Blick auf Makefile.am

Anjutas minimales 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.

## Hinzufügen einer Bibliothek

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

### Verwendung der 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 mit 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.

#### Mit 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  --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`.

#### Mit einem Autoconf-Makro

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.

### Verwendung von Anjuta

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

#### Mit 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 mit 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.

#### Ohne 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.

## Ressourcen

Hier finden Sie einige Links zu Referenzdokumenten, die sich mit den Autotools im Allgemeinen sowie mit Autoconf und Automake im Besonderen befassen.

Englisch

  - Zunächst können Sie sich die Handbücher von Autoconf, Automake, Libtool, make und M4 anschauen.

  - Das Autobook exklärt detailliert, wie die Autotools funktionieren.

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

  - Hier und hier sind zwei weitere Tutorials zu den Autotools.

Französisch

  Hier finden Sie einige Präsentationsfolien eines Lehrers der Ecole Nationale Supérieure des Télecoms über die Autotools.

Japanisch

  Ein Tutorial zu Autoconf und 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.