\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{minted}
\usepackage{hyperref}

\mode<presentation>
\usetheme{Bootlin}

\title{Autotools: a tutorial}
\authors{Thomas Petazzoni}
\institute{Bootlin}

\setcounter{tocdepth}{2}

\setbeamerfont{block title}{size=\scriptsize}

\begin{document}

\begin{frame}{Embedded Linux Conference 2016}
  \begin{center}
    \huge
    GNU Autotools: a tutorial
  \end{center}
\end{frame}

\begin{frame}{Thomas Petazzoni}
  \begin{columns}
    \column{0.7\textwidth}
  \begin{itemize}
  \item CTO and Embedded Linux engineer at {\bf Bootlin}
    \begin{itemize}
    \item Embedded Linux specialists.
    \item Development, consulting and training.
    \item \url{http://bootlin.com}
    \end{itemize}
  \item Contributions
    \begin{itemize}
    \item {\bf Kernel support for the Marvell Armada} ARM SoCs from
      Marvell
    \item Major contributor to {\bf Buildroot}, an open-source, simple and
      fast embedded Linux build system
    \end{itemize}
  \item Living in {\bf Toulouse}, south west of France
  \end{itemize}
  \column{0.3\textwidth}
  \includegraphics[width=0.9\textwidth]{2penguins.png}
\end{columns}
\end{frame}

\begin{frame}
  \begin{center}
    When talking about {\em autotools}, most people think:\\
    \pause
    \includegraphics[height=0.8\textheight]{die-autotools.jpg}\\
    \pause
    But this is a German book, really about the autotools!
  \end{center}
\end{frame}

\begin{frame}{Autotools, why?}
  \begin{itemize}
  \item Yes, the {\em autotools} are old
  \item Yes, they have their pain points
  \item Yes, people hate them
  \item Due to this, people tend to roll-their-own, and roll-their-own
    build systems tend to be even worse than the {\em autotools}
  \item But
    \begin{itemize}
    \item They bring a number of very useful benefits
    \item They are not that complicated when you take the time to get
      back to the basics
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Autotools: benefits}
  \begin{itemize}
  \item Standardized build procedure and behavior: users know how to
    build things that use the {\em autotools}
    \begin{itemize}
    \item Good for human users, but also for build systems
    \end{itemize}
  \item Proper handling for diverted installation
    \begin{itemize}
    \item I.e. build with \code{prefix=/usr}, but divert the
      installation to another directory. Needed for cross-compilation.
    \end{itemize}
  \item Built-in support for out-of-tree build
  \item Built-in handling of dependencies on header files
  \item Support for cross-compilation aspects
  \item Somewhat esoteric, but standardized languages used
    \begin{itemize}
    \item Learn once, use for many projects
    \item New contributors are more likely to know the {\em autotools}
      than your own custom thing
    \end{itemize}
  \item Of course, there are alternatives, {\em CMake} being the most
    interesting and widely used.
  \end{itemize}
\end{frame}

\begin{frame}{Disclaimer}
  \begin{itemize}
    \item I am not an autotools expert
    \item I don't know the internals of autotools, only their usage
    \item This tutorial will only cover the basics aspects
      \begin{itemize}
      \item Sufficient to understand the autoconf/automake documentation
      \item Sufficient to understand most existing build systems
      \end{itemize}
    \item Won't cover many advanced aspects
  \end{itemize}
\end{frame}

\begin{frame}{Autotools tutorial: agenda}
  \begin{enumerate}
  \item User point of view
  \item {\em autoconf} basics
  \item {\em automake} basics
  \item {\em autoconf} advanced
  \item {\em automake} advanced
  \end{enumerate}
\end{frame}

\subsection{User point of view}

\begin{frame}{Using {\em autotools} based packages}
  \begin{itemize}
  \item The basic steps to build an {\em autotools} based software
    component are:
    \begin{enumerate}
    \item {\bf Configuration}\\
      \code{./configure}\\
      Will look at the available build environment, verify required
      dependencies, generate \code{Makefile}s and a \code{config.h}
    \item {\bf Compilation}\\
      \code{make}\\
      Actually builds the software component, using the generated
      Makefiles.
    \item {\bf Installation}\\
      \code{make install}\\
      Installs what has been built.
    \end{enumerate}
  \end{itemize}
\end{frame}

\begin{frame}{What is {\tt configure} doing?}
  \begin{center}
    \includegraphics[width=\textwidth]{what-configure-does.pdf}
  \end{center}
\end{frame}

\begin{frame}{Standard Makefile targets}
  \begin{itemize}
  \item \code{all}, builds everything. The default target.
  \item \code{install}, installs everything that should be installed.
  \item \code{install-strip}, same as \code{install}, but then strips
    debugging symbols
  \item \code{uninstall}
  \item \code{clean}, remove what was built
  \item \code{distclean}, same as \code{clean}, but also removes the
    generated {\em autotools} files
  \item \code{check}, run the test suite
  \item \code{installcheck}, check the installation
  \item \code{dist}, create a tarball
  \end{itemize}
\end{frame}

\begin{frame}{Standard filesystem hierarchy}
  \begin{itemize}
  \item \code{prefix}, defaults to {\em /usr/local}
    \begin{itemize}
    \item \code{exec-prefix}, defaults to \code{prefix}
      \begin{itemize}
      \item \code{bindir}, for programs, defaults to \code{exec-prefix/}{\em bin}
      \item \code{libdir}, for libraries, defaults to \code{exec-prefix/}{\em lib}
      \end{itemize}
    \end{itemize}
  \item \code{includedir}, for headers, defaults to \code{prefix/}{\em include}
  \item \code{datarootdir}, defaults to \code{prefix/}{\em share}
    \begin{itemize}
    \item \code{datadir}, defaults to \code{datarootdir}
    \item \code{mandir}, for man pages, defaults to \code{datarootdir/}{\em man}
    \item \code{infodir}, for info documents, defaults to \code{datarootdir/}{\em info}
    \end{itemize}
  \item \code{sysconfdir}, for configuration files, defaults to
    \code{prefix/}{\em etc}
  \item \code{--<option>} available for each of them
    \begin{itemize}
    \item E.g: \code{./configure --prefix=~/sys/}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Standard configuration variables}
  \begin{itemize}
  \item \code{CC}, C compiler command
  \item \code{CFLAGS}, C compiler flags
  \item \code{CXX}, C++ compiler command
  \item \code{CXXFLAGS}, C++ compiler flags
  \item \code{LDFLAGS}, linker flags
  \item \code{CPPFLAGS}, C/C++ preprocessor flags
  \item and many more, see \code{./configure --help}
  \item E.g: \code{./configure CC=arm-linux-gcc}
  \end{itemize}
\end{frame}

\begin{frame}{System types: build, host, target}
  \begin{itemize}
  \item {\em autotools} identify three {\bf system types}:
    \begin{itemize}
    \item {\bf build}, which is the system where the build takes place
    \item {\bf host}, which is the system where the execution of the
      compiled code will take place
    \item {\bf target}, which is the system for which the program will
      generate code. This is only used for compilers, assemblers,
      linkers, etc.
    \end{itemize}
  \item Corresponding \code{--build}, \code{--host} and
    \code{--target} {\em configure} options.
    \begin{itemize}
    \item They are all automatically {\em guessed} to the current
      machine by default
    \item \code{--build}, generally does not need to be changed
    \item \code{--host}, must be overridden to do cross-compilation
    \item \code{--target}, needs to be overridden if needed (to
      generate a cross-compiler, for example)
    \end{itemize}
  \item Arguments to these options are {\em configuration names}, also
    called {\em system tuples}
  \end{itemize}
\end{frame}

\begin{frame}{System type: native compilation example}
  \begin{center}
    Demo\\
    (based on the kmod source code)
  \end{center}
\end{frame}

\begin{frame}{Cross-compilation}
  \begin{itemize}
  \item By default, {\em autotools} will guess the {\bf host} machine
    as being the current machine
  \item To cross-compile, it must be overridden by passing the
    \code{--host} option with the appropriate {\em configuration name}
  \item By default, {\em autotools} will try to use the
    cross-compilation tools that use the {\em configuration name} as
    their prefix.
  \item If not, the variables \code{CC}, \code{CXX}, \code{LD},
    \code{AR}, etc. can be used to point to the cross-compilation
    tools.
  \end{itemize}
\end{frame}

\begin{frame}{Out of tree build}
  \begin{itemize}
  \item {\em autotools} support out of tree compilation by default
  \item Consists in doing the build in a directory separate from the
    source directory
  \item Allows to:
    \begin{itemize}
    \item Build different configurations without having to rebuild
      from scratch each time.
    \item Not clutter the source directory with build related files
    \end{itemize}
  \item To use out of tree compilation, simply run the configure
    script from another empty directory
    \begin{itemize}
    \item This directory will become the build directory
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Out of tree build: example}
  \begin{center}
    Demo
  \end{center}
\end{frame}

\begin{frame}[fragile]{Diverted installation with DESTDIR}

  \begin{itemize}

  \item By default, \code{make install} installs to the directories
    given in \code{--prefix} and related options.

  \item In some situations, it is useful to {\em divert} the
    installation to another directory
    \begin{itemize}
    \item Cross-compilation, where the build machine is not the
      machine where applications will be executed.
    \item Packaging, where the installation needs to be done in a
      temporary directory.
    \end{itemize}

  \item Achieved using the \code{DESTDIR} variable.
  \end{itemize}

  Demo!

\end{frame}

\begin{frame}{{\tt --prefix} or {\tt DESTDIR} ?}
  \begin{itemize}
  \item \code{--prefix} and \code{DESTDIR} are often misunderstood
  \item \code{--prefix} is the location where the programs/libraries
    will be placed when executed on the {\em host machine}
  \item \code{DESTDIR} is a way of temporarily diverting the
    installation to a different location.

  \item For example, if you use \code{--prefix=/home/<foo>/sys/usr},
    then binaries/libraries will look for icons in
    \code{/home/<foo>/sys/usr/share/icons}
    \begin{itemize}
    \item Good for native installation in \code{/home/<foo>/sys}
    \item {\bf Bad} for cross-compilation where the binaries will
      ultimately be in \code{/usr}
    \end{itemize}

  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt --prefix} or {\tt DESTDIR} use cases}
  \begin{itemize}
  \item Native compilation, install system-wide in \code{/usr}
    \begin{block}{}
{\tiny
\begin{verbatim}
$ ./configure --prefix=/usr
$ make
$ sudo make install
\end{verbatim}}
\end{block}
\item Native compilation, install in a user-specific directory:
  \begin{block}{}
{\tiny
\begin{verbatim}
$ ./configure --prefix=/home/<foo>/sys/
$ make
$ make install
\end{verbatim}}
\end{block}
\item Cross-compilation, install in \code{/usr}, diverted to a
  temporary directory where the system for the target is built
  \begin{block}{}
{\tiny
\begin{verbatim}
$ ./configure --prefix=/usr
$ make
$ make DESTDIR=/home/<foo>/target-rootfs/ install
\end{verbatim}}
\end{block}

\end{itemize}

\end{frame}

\begin{frame}{Analyzing issues}
  \begin{itemize}
  \item \code{autoconf} keeps a log of all the tests it runs in a file
    called \code{config.log}
  \item Very useful for analysis of \code{autoconf} issues
  \item It contains several sections: {\em Platform}, {\em Core
      tests}, {\em Running config.status}, {\em Cache variables}, {\em
      Output variables}, {\em confdefs.h}
  \item The end of the {\em Core tests} section is usually the most
    interesting part
    \begin{itemize}
    \item This is where you would get more details about the reason of
      the {\em configure} script failure
    \end{itemize}
  \item At the beginning of
    \code{config.log} you can also see the
    \code{./configure} line that was used, with all options and environment variables.
  \end{itemize}
\end{frame}

% \begin{frame}[fragile]{{\tt config.log} example}

% \begin{block}{}
% {\tiny
% \begin{verbatim}
% $ ./configure ...
% [...]
% checking for TIFFFlushData in -ltiff34... no
% configure: WARNING: *** TIFF loader will not be built (TIFF library not found) ***
% configure: error: 
% *** Checks for TIFF loader failed. You can build without it by passing
% *** --without-libtiff to configure but some programs using GTK+ may
% *** not work properly

% $ cat config.log
% [...]
% configure:18177: .../usr/bin/x86_64-linux-gcc -std=gnu99 -o conftest -D_LARGEFILE_SOURCE
%    -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64   -Os  -static -Wall -D_LARGEFILE_SOURCE
%     -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DG_DISABLE_SINGLE_INCLUDES  -static
%     conftest.c -ltiff34 -ljpeg -lz -lm  >&5
% .../host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.8.4/../../../../
%     x86_64-buildroot-linux-uclibc/bin/ld: cannot find -ltiff34
% .../host/opt/ext-toolchain/bin/../lib/gcc/x86_64-buildroot-linux-uclibc/4.8.4/../../../../
%    x86_64-buildroot-linux-uclibc/bin/ld: cannot find -ljpeg
% collect2: error: ld returned 1 exit status
% configure:18177: $? = 1
% configure: failed program was:
% [...]
% configure:18186: result: no
% configure:18199: WARNING: *** TIFF loader will not be built (TIFF library not found) ***
% configure:18210: error: 
% *** Checks for TIFF loader failed. You can build without it by passing
% *** --without-libtiff to configure but some programs using GTK+ may
% *** not work properly
% \end{verbatim}}
% \end{block}

% \end{frame}

\begin{frame}{autotools: {\em autoconf} and {\em automake}}
  \begin{itemize}
  \item The \code{configure} script is a shell script generated from
    \code{configure.ac} by a program called \code{autoconf}
    \begin{itemize}
    \item \code{configure.ac} used to be named \code{configure.in} but
      this name is now deprecated
    \item Written in shell script, augmented with numerous {\em m4}
      macros
    \end{itemize}
  \item The \code{Makefile.in} are generated from \code{Makefile.am}
    files by a program called \code{automake}
    \begin{itemize}
    \item Uses special \code{make} variables that are expanded in
      standard \code{make} constructs
    \end{itemize}
  \item Some auxilliary tools like \code{autoheader} or \code{aclocal}
    are also used
    \begin{itemize}
    \item \code{autoheader} is responsible for generating the {\em
        configuration header} template, \code{config.h.in}
    \end{itemize}
  \item Generated files (\code{configure}, \code{Makefile.in},
    \code{Makefile}) should not be modified.
    \begin{itemize}
    \item Reading them is also very difficult. Read the real source
      instead!
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Overall organization}

  \begin{center}
    \includegraphics[width=\textwidth]{autoreconf.pdf}
  \end{center}

\end{frame}

\begin{frame}[fragile]{Cache variables}

  \begin{itemize}

  \item Each test done by a \code{configure.ac} script is associated
    with a {\em cache variable}

  \item The list of such variables and their values is visible in
    \code{config.log}:
    \begin{block}{}
{\tiny
\begin{verbatim}
## ---------------- ##
## Cache variables. ##
## ---------------- ##
ac_cv_build=x86_64-unknown-linux-gnu
ac_cv_c_compiler_gnu=yes
[...]
ac_cv_path_SED=/bin/sed
\end{verbatim}}
    \end{block}

  \item If the autodetected value is not correct for some reason, you
    can override any of these variables in the environment:
    \begin{block}{}
{\scriptsize
\begin{verbatim}
$ ac_cv_path_SED=/path/to/sed ./configure
\end{verbatim}}
    \end{block}

  \item This is sometimes useful when cross-compiling, since some
    tests are not always cross-compilation friendly.

  \end{itemize}

\end{frame}

\begin{frame}{Distribution}
  \begin{itemize}
  \item In general:
    \begin{itemize}
    \item When a software is published as a {\em tarball}, the
      \code{configure} script and \code{Makefile.in} files are already
      generated and part of the tarball.
    \item When a software is published through {\em version control
        system}, only the real sources \code{configure.ac} and
      \code{Makefile.am} are available.
    \end{itemize}
  \item There are some exceptions (like tarballs not having
    pre-generated \code{configure}/\code{Makefile.in})
  \item Do not version control generated files!
  \end{itemize}
\end{frame}

\begin{frame}{Regenerating {\em autotools} files: {\tt autoreconf}}
  \begin{itemize}
  \item To generate all the files used by {\em autotools}, you could
    call \code{automake}, \code{autoconf}, \code{aclocal},
    \code{autoheader}, etc. manually.
    \begin{itemize}
    \item But it is not very easy and efficient.
    \end{itemize}
  \item A tool called \code{autoreconf} automates this process
    \begin{itemize}
    \item Useful option: \code{-i} or \code{--install}, to ask
      \code{autoreconf} to copy missing auxiliary files
    \end{itemize}
  \item Always use \code{autoreconf}!
  \end{itemize}
\end{frame}

\subsection{{\bf autoconf} basics}

\begin{frame}{{\tt configure.ac} language}
  \begin{itemize}
  \item Really a shell script
  \item Processed through the \code{m4} preprocessor
  \item Shell script augmented with special constructs for portability:
    \begin{itemize}
    \item \code{AS_IF} instead of shell \code{if ... then .. fi}
    \item \code{AS_CASE} instead of shell \code{case ... esac}
    \item etc.
    \end{itemize}
  \item {\em autoconf} provides a large set of {\em m4} macros to
    perform most of the usual tests
  \item Make sure to quote macro arguments with \code{[]}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Minimal {\tt configure.ac}}
  \begin{block}{configure.ac}
  \begin{minted}{bash}
AC_INIT([hello], [1.0])
AC_OUTPUT
  \end{minted}
  \end{block}
  \begin{itemize}
  \item \code{AC_INIT}
    \begin{itemize}
    \item Every configure script must call \code{AC_INIT} before doing
      anything else that produces output.
    \item Process any command-line arguments and perform
      initialization and verification.
    \item Prototype:\\
      \code{AC_INIT (package, version, [bug-report], [tarname], [url])}
    \end{itemize}
  \item \code{AC_OUTPUT}
    \begin{itemize}
    \item Every \code{configure.ac}, should finish by calling
      \code{AC_OUTPUT}.
    \item Generates and runs \code{config.status}, which in turn creates the
      makefiles and any other files resulting from configuration.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Minimal {\tt configure.ac} example}
  \begin{center}
    Demo 01
  \end{center}
\end{frame}

\begin{frame}{Additional basic macros}
  \begin{itemize}
  \item \code{AC_PREREQ}
    \begin{itemize}
    \item Verifies that a recent enough version of {\em autoconf} is used
    \item \code{AC_PREREQ([2.68])}
    \end{itemize}
  \item \code{AC_CONFIG_SRCDIR}
    \begin{itemize}
    \item Gives the path to one source file in your project
    \item Allows {\em autoconf} to check that it is really where it
      should be
    \item \code{AC_CONFIG_SRCDIR([hello.c])}
    \end{itemize}
  \item \code{AC_CONFIG_AUX_DIR}
    \begin{itemize}
    \item Tells {\em autoconf} to put the auxiliary build tools it
      requires in a different directory, rather than the one of
      \code{configure.ac}
    \item Useful to keep cleaner build directory
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Additional basic macros}
  \begin{center}
    Demo 02
  \end{center}
\end{frame}

\begin{frame}{Checking for basic programs}
  \begin{itemize}
  \item \code{AC_PROG_CC}, makes sure a C compiler is available
  \item \code{AC_PROG_CXX}, makes sure a C++ compiler is available
  \item \code{AC_PROG_AWK}, \code{AC_PROG_GREP}, \code{AC_PROG_LEX},
    \code{AC_PROG_YACC}, etc.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Checking for basic programs: example}
  \begin{center}
    Demo 03
  \end{center}
\end{frame}

\begin{frame}{{\tt AC\_CONFIG\_FILES}}
  \begin{itemize}
  \item \code{AC_CONFIG_FILES (file..., [cmds], [init-cmds])}
  \item Make \code{AC_OUTPUT} create each file by copying an input
    \code{file} (by default \code{file.in}), substituting the {\em
      output variable values}.
  \item Typically used to turn the Makefile templates
    \code{Makefile.in} files into final \code{Makefile}.
  \item Example:\\
    \code{AC_CONFIG_FILES([Makefile src/Makefile])}
  \item \code{cmds} and \code{init-cmds} are rarely used, see the {\em
      autoconf} documentation for details.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Output variables}
  \begin{itemize}
  \item {\em autoconf} will replace \code{@variable@} constructs by
    the appropriate values in files listed in \code{AC_CONFIG_FILES}
  \item Long list of standard variables replaced by {\em autoconf}
  \item Additional shell variables declared in \code{configure.ac} can
    be replaced using \code{AC_SUBST}
  \item The following three examples are equivalent:
    \begin{block}{}
\begin{verbatim}
AC_SUBST([FOO], [42])
\end{verbatim}
    \end{block}

    \begin{block}{}
\begin{verbatim}
FOO=42
AC_SUBST([FOO])
\end{verbatim}
    \end{block}

    \begin{block}{}
\begin{verbatim}
AC_SUBST([FOO])
FOO=42
\end{verbatim}
    \end{block}

  \end{itemize}
\end{frame}

\begin{frame}{{\tt AC\_CONFIG\_FILES} example}
  \begin{center}
    Demo 04
  \end{center}
\end{frame}

\begin{frame}[fragile]{{\tt configure.ac}: a shell script}

\begin{itemize}
\item It is possible to include normal shell constructs in
  \code{configure.ac}
\item Beware to not use {\em bashisms}: use only POSIX compatible
  constructs
\item Most configure scripts use directly shell constructs, but
  \code{AS_ECHO}, \code{AS_IF}, etc. are available.
\end{itemize}

\begin{center}
  Demo 05 and 05b
\end{center}

\end{frame}

\begin{frame}{Writing {\tt Makefile.in}?}
  \begin{itemize}
  \item At this point, we have seen the very basics of {\em autoconf}
    to perform the configuration side of our software
  \item We could use \code{AC_CONFIG_FILES} to generate
    \code{Makefile} from \code{Makefile.in}
  \item However, writing a \code{Makefile.in} properly is not easy,
    especially if you want to:
    \begin{itemize}
    \item be portable
    \item automatically handle dependencies
    \item support conditional compilation, out-of-tree build, diverted
      installation, cross-compilation, etc.
    \end{itemize}
  \item For these reasons, \code{Makefile.in} are typically not
    written manually, but generated by {\em automake} from a
    \code{Makefile.am} file
  \end{itemize}
\end{frame}

\subsection{{\bf automake} basics}

\begin{frame}{{\tt Makefile.am} language}
  \begin{itemize}
  \item Really just a \code{Makefile}
    \begin{itemize}
    \item You can include regular {\em make} code
    \end{itemize}
  \item Augmented with {\em automake} specific constructs that are
    expanded into regular {\em make} code
  \item For most situations, the {\em automake} constructs are
    sufficient to express what needs to be built
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt Makefile.am} minimal example}

  \begin{itemize}
  \item The minimal example of \code{Makefile.am} to build just one C
    file into a program is only two lines:
  \end{itemize}

  \begin{block}{Makefile.am}
\begin{verbatim}
bin_PROGRAMS = hello
hello_SOURCES = main.c
\end{verbatim}
  \end{block}

  \begin{itemize}
  \item Will compile \code{main.c} to \code{main.o}
  \item And link \code{hello.o} into the \code{hello} executable
  \item Which will be installed in \code{$prefix/bin}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Enabling {\em automake} in {\tt configure.ac}}
  \begin{itemize}
  \item To enable {\em automake} usage in \code{configure.ac}, you
    need:
    \begin{itemize}
    \item A call to \code{AM_INIT_AUTOMAKE}
    \item Generate the \code{Makefile} using \code{AC_CONFIG_FILES}
    \end{itemize}
  \item {\em automake} will generate the \code{Makefile.in} at {\em
      autoreconf} time, and {\em configure} will generate the final
    \code{Makefile}
  \end{itemize}

  \begin{block}{configure.ac}
\begin{verbatim}
AC_INIT([hello], [1.0])
AM_INIT_AUTOMAKE([foreign 1.13])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
\end{verbatim}
  \end{block}

\end{frame}

\begin{frame}{First {\tt automake} demo}
  \begin{center}
    Demo 06
  \end{center}
\end{frame}

\begin{frame}{{\tt AM\_INIT\_AUTOMAKE}}

  \begin{itemize}
  \item \code{AM_INIT_AUTOMAKE([OPTIONS])}
  \item Interesting options:
    \begin{itemize}
    \item \code{foreign}, tells {\em automake} to not require all the
      GNU Coding Style files such as \code{NEWS}, \code{README},
      \code{AUTHORS}, etc.
    \item \code{dist-bzip2}, \code{dist-xz}, etc. tell {\em automake}
      which tarball format should be generated by \code{make dist}
    \item \code{subdir-objects} tells {\em automake} that the objects
      are placed into the subdirectory of the build directory
      corresponding to the subdirectory of the source file
    \item {\em version}, e.g \code{1.14.1}, tells the minimal
      \code{automake} version that is expected
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt Makefile.am} syntax}
  \begin{itemize}
  \item An {\em automake} parsable \code{Makefile.am} is composed of {\bf
      product list variables}:
    \begin{block}{}
\begin{verbatim}
bin_PROGRAMS = hello
\end{verbatim}
\end{block}
  \item And {\bf product source variables}:
    \begin{block}{}
\begin{verbatim}
hello_SOURCES = main.c
\end{verbatim}
\end{block}

\end{itemize}
\end{frame}

\begin{frame}[fragile]{Product list variables}

    \begin{block}{}
{\small
\begin{verbatim}
[modifier-list]prefix_PRIMARY = product1 product2 ...
\end{verbatim}}
\end{block}

  \begin{itemize}

\item \code{prefix} is the installation prefix, i.e. where it should be
  installed
  \begin{itemize}
  \item All \code{*dir} variables from {\em autoconf} can be used,
    without their \code{dir} suffix: use \code{bin} for \code{bindir}
  \item E.g.: \code{bindir}, \code{libdir}, \code{includedir},
    \code{datadir}, etc.
  \end{itemize}

\item \code{PRIMARY} describes what type of things should be built:
  \begin{itemize}
  \item \code{PROGRAMS}, for executables
  \item \code{LIBRARIES}, \code{LTLIBRARIES}, for libraries
  \item \code{HEADERS}, for publicly installed header files
  \item \code{DATA}, arbitrary data files
  \item \code{PYTHON}, \code{JAVA}, \code{SCRIPTS}
  \item \code{MANS}, \code{TEXINFOS}, for documentation
  \end{itemize}

\item After the \code{=} sign, list of products to be generated

\end{itemize}

\end{frame}

\begin{frame}[fragile]{Product source variables}

    \begin{block}{}
{\small
\begin{verbatim}
[modifier-list]product_SOURCES = file1 file2 ...
\end{verbatim}}
\end{block}

\begin{itemize}

\item The \code{product} is the normalized name of the product, as
  listed in a {\em product list variable}
  \begin{itemize}
  \item The normalization consists in replacing special characters
    such as \code{.} or \code{+} by \code{_}. For example,
    \code{libfoo+.a} in a {\em product list variable} gives the
    \code{libfoo__a_SOURCES} product source variable.
  \end{itemize}
\item \code{_SOURCES} is always used, it's not like a configurable {\em
    primary}.
  \begin{itemize}
  \item Contains the list of files containing the source code for the
    product to be built.
  \item Both source files {\em and} header files should be listed.
  \end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{More complicated {\tt automake} example}
  \begin{center}
    Demo 07
  \end{center}
\end{frame}

\subsection{{\bf autoconf} advanced}

\begin{frame}[fragile]{Configuration header}
  \begin{itemize}
  \item Very often, C/C++ code needs to know the result of certain
    tests done by the \code{configure} script.
  \item A template C header file can be automatically generated by
    \code{autoheader}, generally named \code{config.h.in}
  \item The final header file is generated by \code{configure},
    generally named \code{config.h}
  \item Declared using \code{AC_CONFIG_HEADERS}
    \begin{block}{\code{configure.ac} extract}
\begin{minted}[fontsize=\scriptsize]{bash}
AC_CONFIG_HEADERS([config.h])
\end{minted}
    \end{block}

    \begin{block}{Example config.h}
\begin{minted}[fontsize=\scriptsize]{c}
/* Define if the complete vga libraries (vga, vgagl) are installed */
/* #undef HAVE_LIBVGA */

/* Define to 1 if you have the <limits.h> header file. */
#define HAVE_LIMITS_H 1
\end{minted}
\end{block}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt AC\_DEFINE}}

  \begin{itemize}
  \item \code{AC_DEFINE} allows to create C definitions in the {\em
      configuration header}
  \item \code{AC_DEFINE (variable, value, description)}
  \end{itemize}

  \begin{block}{\code{configure.ac}}
\begin{minted}{bash}
AC_DEFINE([FOOBAR], [42], [This is the foobar value])
\end{minted}
  \end{block}

  \begin{center}
    Demo 08
  \end{center}

\end{frame}

\begin{frame}{Checking for functions}
  \begin{itemize}
  \item You may need to check if certain functions are available
    and/or meet certain characteristics
  \item Family of \code{AC_FUNC_*} macros
    \begin{itemize}
    \item \code{AC_FUNC_FORK}, \code{AC_FUNC_GETLOADAVG}, \code{AC_FUNC_MALLOC}, etc.
    \item See {\em autoconf} manual for details
    \end{itemize}
  \item \code{AC_CHECK_FUNC[S]} to check for generic functions
    \begin{itemize}
    \item \code{AC_CHECK_FUNC (function, [action-if-found],
        [action-if-not-found])}
    \item \code{AC_CHECK_FUNCS (function..., [action-if-found],
        [action-if-not-found])}
    \item Results available
      \begin{itemize}
      \item \code{ac_cv_func_<function>} variable in
        \code{configure.ac}
      \item \code{HAVE_<FUNCTION>} defines in {\em configuration
          headers}
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt AC\_CHECK\_FUNCS()} example}
  \begin{center}
    Demo 09
  \end{center}
\end{frame}

\begin{frame}{Checking for headers}

  \begin{itemize}
  \item Much like \code{AC_FUNC_*} and \code{AC_CHECK_FUNC[S]}, but for headers
  \item Variety of \code{AC_HEADER_*} macros
    \begin{itemize}
    \item Check the autoconf manual for details
    \end{itemize}
  \item \code{AC_CHECK_HEADER[S]} for generic headers checking
    \begin{itemize}
    \item \code{AC_CHECK_HEADER (header-file, [action-if-found], [action-if-not-found], [includes])}
    \item \code{AC_CHECK_HEADERS (header-file..., [action-if-found], [action-if-not-found], [includes])}
    \item Results available in:
      \begin{itemize}
      \item \code{ac_cv_header_<header-file>} variable in
        \code{configure.ac}
      \item \code{HAVE_<HEADER>_H} define in \code{config.h}
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt AC\_CHECK\_HEADERS} example}

\begin{block}{\code{configure.ac}}
\begin{minted}[fontsize=\scriptsize]{bash}
[...]
AC_CHECK_HEADERS([spawn.h],
        [echo "Header spawn.h was found"; has_spawn=yes],
        [echo "Header spawn.h was not found"])
echo ${has_spawn}
[...]
\end{minted}
\end{block}

\begin{block}{Execution of \code{./configure}}
\begin{minted}[fontsize=\scriptsize]{console}
$ ./configure
[...]
checking for spawn.h... yes
Header spawn.h was found
yes
[...]
\end{minted}
\end{block}

\end{frame}

\begin{frame}[fragile]{Checking for libraries}
  \begin{block}{}
\begin{minted}[fontsize=\small]{bash}
AC_SEARCH_LIBS (function, search-libs,
                [action-if-found], [action-if-not-found],
                [other-libraries])
\end{minted}
  \end{block}

  \begin{itemize}
  \item Search for a library defining \code{function}, by linking a
    simple program calling \code{function}
  \item Tries first with no library, and then with the different
    libraries in \code{search-libs}, one after the other.
  \item If a library is found, \code{-llibrary} is prepended to the
    \code{LIBS} variable, so programs will be linked against
    it. \code{action-if-found} is executed.
  \item If not, \code{action-if-not-found} is executed
  \item \code{other-libraries} allows to pass additional
    \code{-l<foo>} arguments that may be needed for the link test to
    succeed.
  \item Result in \code{ac_cv_search_<function>}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt AC\_SEARCH\_LIBS} example}
  \begin{center}
    Demo 10
  \end{center}
\end{frame}

\begin{frame}{Other checks}
  \begin{itemize}
  \item {\bf Programs} with \code{AC_CHECK_PROGS}
    \begin{itemize}
    \item \code{AC_CHECK_PROGS(PERL, [perl5 perl])}
    \end{itemize}
  \item {\bf Declarations} with \code{AC_CHECK_DECLS}
  \item {\bf Structure members} with \code{AC_CHECK_MEMBERS}
  \item {\bf Types} with \code{AC_CHECK_TYPES}
    \begin{itemize}
    \item \code{AC_CHECK_TYPES(int8_t)}
    \end{itemize}
  \item See the {\em autoconf} manual for details
  \end{itemize}
\end{frame}

\begin{frame}{Writing new tests}
  \begin{itemize}
  \item You can create your own tests by pre-processing, compiling or
    linking small test programs:
    \begin{itemize}
    \item Pre-processing test\\
      {\small \code{AC_PREPROC_IFELSE (input, [action-if-true], [action-if-false])}}
    \item Compiling test\\
      {\small \code{AC_COMPILE_IFELSE (input, [action-if-true], [action-if-false])}}
    \item Link test\\
      {\small \code{AC_LINK_IFELSE (input, [action-if-true], [action-if-false])}}
    \end{itemize}
  \item Input should be formatted with \code{AC_LANG_SOURCE} or
    \code{AC_LANG_PROGRAM}
  \item Runtime tests can also be created
    \begin{itemize}
    \item Beware, by nature, they cannot work for cross-compilation!
    \item \code{AC_RUN_IFELSE}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Writing new tests: {\tt AC\_LINK\_IFELSE}}
  \begin{center}
    Demo 11
  \end{center}
\end{frame}

\begin{frame}{Printing messages}
  \begin{itemize}
  \item When creating new tests, you may want to show messages,
    warnings, errors, etc.
  \item \code{AC_MSG_CHECKING (feature-description)}
    \begin{itemize}
    \item Notify the user that configure is checking for a
      particular feature.
    \end{itemize}
  \item \code{AC_MSG_RESULT (result-description)}
    \begin{itemize}
    \item Notify the user of the results of a check
    \end{itemize}
  \item \code{AC_MSG_NOTICE (message)}
    \begin{itemize}
    \item Deliver the {\em message} to the user.
    \end{itemize}
  \item \code{AC_MSG_ERROR (error-description, [exit-status = ‘$?/1’])}
    \begin{itemize}
    \item Notify the user of an error that prevents configure from
      completing.
    \end{itemize}
  \item \code{AC_MSG_WARN (problem-description)}
    \begin{itemize}
    \item Notify the configure user of a possible problem.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Printing messages: example}
  \begin{center}
    Demo 11 continued
  \end{center}
\end{frame}

\begin{frame}{Cache variables}
  \begin{itemize}
  \item Each test done by {\em autoconf} is normally associated to a
    {\bf cache variable}.
    \begin{itemize}
    \item Allows to speed-up the configure step by passing a cache
      file with pre-defined values.
    \item Allows to override the results of tests if they are not
      correct for some reason
    \end{itemize}
  \item \code{AC_CACHE_VAL(cache-id, commands-to-set-it)}, runs {\em
      commands} if {\em cache-id} is not already set. {\em commands}
    must set the {\em cache-id} variable and have no side-effect.
  \item \code{AC_CACHE_CHECK(message, cache-id, commands)}, wrapper
    around \code{AC_CACHE_VAL} to print the message.
  \end{itemize}
\end{frame}

\begin{frame}{Cache variables demo}
  \begin{center}
    Demo 11 further continued
  \end{center}
\end{frame}

\begin{frame}[fragile]{Using external software}
  \begin{itemize}
  \item When a package uses external software,
    \code{--with-<package>=<arg>} and \code{--without-<package>}
    options are generally offered to control usage of the external
    software.
  \item Implemented using the \code{AC_ARG_WITH} macro.
    \begin{block}{}
\begin{minted}[fontsize=\small]{bash}
AC_ARG_WITH (package, help-string,
             [action-if-given], [action-if-not-given])
\end{minted}
    \end{block}
    \begin{itemize}
    \item \code{package} gives the name of the option
    \item \code{help-string} is the help text, visible in
      \code{./configure --help}
    \item \code{action-if-given} is executed when the option is used,
      either positively (\code{--with}) or negatively (\code{--without})
    \item \code{action-if-not-given} is executed when the option is not
      used
    \item \code{<arg>} available as \code{$withval} inside {\em
        action-if-given}, \code{$with_<package>} outside.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Package options}

  \begin{itemize}

  \item When a package offers optional features,
    \code{--enable-<feature>} and \code{--disable-<feature>} options
    are generally offered to control the optional feature.
  \item Implemented using the \code{AC_ARG_ENABLE} macro.
\begin{block}{}
\begin{minted}[fontsize=\small]{bash}
AC_ARG_ENABLE (feature, help-string,
               [action-if-given], [action-if-not-given])
\end{minted}
\end{block}
\item Usage very similar to the one of \code{AC_ARG_WITH}
\item Value available as \code{$enableval} inside {\em
    action-if-given}, \code{$enable_<feature>} outside.
\end{itemize}

\end{frame}

\begin{frame}[fragile]{Formatting the help string}
  \begin{itemize}
  \item To help formatting the help string, {\em autoconf} provides
    the \code{AS_HELP_STRING} macro
  \item Allows to properly align the different options in the
    \code{./configure --help} output
\begin{block}{}
\begin{minted}[fontsize=\small]{bash}
AS_HELP_STRING (left-hand-side, right-hand-side,
      [indent-column = '26'], [wrap-column = '79'])
\end{minted}
\end{block}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt AC\_ARG\_ENABLE} example}
  \begin{center}
    Demo 12
  \end{center}
\end{frame}

\begin{frame}{Using pkg-config with {\tt autoconf}}

  \begin{itemize}

  \item To find libraries, a much better solution than
    \code{AC_SEARCH_LIBS} is to use {\bf pkg-config}

  \item pkg-config is a database of small text files, using the
    \code{.pc} extension, describing how to use a given library
    \begin{itemize}
    \item installed in \code{usr/lib/pkgconfig} on most systems
    \item installed by most modern libraries
    \end{itemize}

  \item The \code{pkg-config} command line tool allows to query this
    database for the compiler and linker flags needed to use a given
    library.

  \item The \code{PKG_CHECK_MODULES} {\em autoconf} macro allows to
    query the pkg-config database.

  \end{itemize}

\end{frame}

\begin{frame}[fragile]{The {\tt PKG\_CHECK\_MODULES} macro}
\begin{itemize}
\item Syntax:
  \begin{block}{}
\begin{minted}[fontsize=\small]{bash}
PKG_CHECK_MODULES(prefix, list-of-modules,
                  action-if-found, action-if-not-found)
\end{minted}
  \end{block}
\item \code{prefix} will be used to create the
  \code{<prefix>_CFLAGS} and \code{<prefix>_LIBS} variables
  \begin{itemize}
  \item Contain the pre-processor and linker flags to use the
    libraries listed in \code{list-of-modules}
  \item Are already \code{AC_SUBST}ed, so can be used directly in
    \code{Makefile.am}
  \end{itemize}
\item \code{list-of-modules} is one or several pkg-config libraries
  \begin{itemize}
  \item Can contain version specifiers, such as \code{foo >= 3 bar
      baz <= 4}
  \end{itemize}
\item Will exit with a failure if one of the dependencies is missing.
\end{itemize}
\end{frame}

\begin{frame}[fragile]{{\tt PKG\_CHECK\_MODULES} example}
  \begin{center}
    Demo 13
  \end{center}
\end{frame}

\begin{frame}{{\tt autoscan}}
  \begin{itemize}
  \item \code{autoscan} is a program provided together with \code{autoconf}
  \item Scans the source tree in the current directory (or the one
    passed as argument)
  \item From that, \code{autoscan}:
    \begin{itemize}
    \item Searches the source files for common portability problems
    \item Checks for incompleteness of the \code{configure.ac} file, if any
    \item Generates \code{configure.scan}, which can be used as a
      preliminary \code{configure.ac}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Additional {\tt m4} macros}
  \begin{itemize}
  \item The core \code{autoconf} macros are installed in
    \code{/usr/share/autoconf/autoconf/}
  \item Additional macros can be installed by other packages in
    \code{/usr/share/aclocal}
    \begin{itemize}
    \item Examples: \code{pkg.m4} (for pkg-config),
      \code{gpg-error.m4}, \code{iconv.m4}, etc.
    \end{itemize}
  \item The {\bf GNU Autoconf Archive} is a collection of more than
    500 macros for \code{autoconf}
    \begin{itemize}
    \item \url{http://www.gnu.org/software/autoconf-archive/}
    \item Example:
      \code{AX_C_LONG_LONG}, {\em Provides a test for the existence of the long long int type and defines HAVE\_LONG\_LONG if it is found.}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{autoconf-archive example}
  \begin{center}
    Demo 14
  \end{center}
\end{frame}

\subsection{{\bf automake} advanced}

\begin{frame}{Subdirectories}
  \begin{itemize}
  \item A project is often organized with multiple directories
  \item \code{automake} offers two options to support this:
    \begin{itemize}
    \item {\bf recursive make}, where a sub-call to \code{make} is made
      for sub-directories, and each directory has its own
      \code{Makefile.am}
    \item {\bf non-recursive make}, where there is a single
      \code{Makefile.am}, building everything
    \end{itemize}
  \item {\bf recursive make} used to be the norm, but has significant
    drawbacks
    \begin{itemize}
    \item Performance for parallel building
    \item {\em Recursive make considered harmful},
      \url{http://aegis.sourceforge.net/auug97.pdf}
    \end{itemize}
  \item {\bf non-recursive make} is more and more commonly used in
    modern projects
    \begin{itemize}
    \item If the \code{Makefile.am} grows too large, one can use
      \code{include} to split it.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Recursive make}

  \begin{itemize}
  \item The \code{SUBDIRS} variable in a \code{Makefile.am} indicates
    the sub-directories that contain other \code{Makefile.am}
  \end{itemize}

  \begin{block}{configure.ac}
\begin{minted}{bash}
AC_CONFIG_FILES([Makefile src/Makefile])
\end{minted}
  \end{block}

  \begin{block}{Makefile.am}
\begin{minted}{make}
SUBDIRS = src
\end{minted}
  \end{block}

  \begin{block}{src/Makefile.am}
\begin{minted}{make}
bin_PROGRAMS = hello
hello_SOURCES = main.c
\end{minted}
  \end{block}
\end{frame}

\begin{frame}[fragile]{Non-recursive make}

  \begin{itemize}
  \item The \code{AM_INIT_AUTOMAKE} macro accepts a
    \code{subdir-objects} argument
  \item If specified, allows a \code{Makefile.am} to reference code in
    another directory
  \end{itemize}

\begin{block}{configure.ac}
\begin{minted}{bash}
AM_INIT_AUTOMAKE([subdir-objects])
AC_CONFIG_FILES([Makefile])
\end{minted}
\end{block}

\begin{block}{Makefile.am}
\begin{minted}{make}
bin_PROGRAMS = hello
hello_SOURCES = src/main.c
\end{minted}
\end{block}

\end{frame}

\begin{frame}{{\tt automake} subdirectories: demo}
  \begin{center}
    Demo 15 and 16
  \end{center}
\end{frame}

\begin{frame}[fragile]{{\em automake} conditionals}

  \begin{itemize}
  \item In order to use a conditional in a \code{Makefile.am}, it must
    be defined in the \code{configure.ac} script.
  \item Done using the \code{AM_CONDITIONAL(conditional, condition)}
    macro
  \end{itemize}

  \begin{block}{configure.ac}
\begin{minted}{bash}
AM_CONDITIONAL([DEBUG], [test "${debug}" = "true"])
\end{minted}
  \end{block}

  \begin{block}{Makefile.am}
\begin{minted}{make}
if DEBUG
...
else
...
endif
\end{minted}
  \end{block}

\end{frame}

\begin{frame}[fragile]{Usage of {\em automake} conditionals}

  \begin{columns}
    \column{0.3\textwidth}
    You cannot use conditionals inside a variable definition
    \begin{block}{Non-working example}
\begin{minted}[fontsize=\tiny]{make}
bin_PROGRAMS = \
      bar \
if DEBUG
      baz \
endif
      foobar
\end{minted}
\end{block}

    \column{0.3\textwidth}
    You should instead use an intermediate variable

    \begin{block}{Working example}
\begin{minted}[fontsize=\tiny]{make}
if DEBUG
DEBUG_PROGS = baz
endif

bin_PROGRAMS = \
      bar \
      $(DEBUG_PROGS) \
      foobar
\end{minted}
\end{block}

    \column{0.3\textwidth}
    Or the \code{+=} assigment sign

    \begin{block}{Working example}
\begin{minted}[fontsize=\tiny]{make}
bin_PROGRAMS = \
      bar \
      foobar

if DEBUG
bin_PROGRAMS += baz
endif
\end{minted}
\end{block}
\end{columns}
\end{frame}

\begin{frame}[fragile]{Conditional example}
  \begin{center}
    Demo 17
  \end{center}
\end{frame}

\begin{frame}{Building shared libraries}
  \begin{itemize}
  \item Building shared libraries is very different between Unix
    variants
  \item A specific tool, called \code{libtool}, was created to
    abstract away the differences between platforms.
  \item Concept called {\em libtool libraries}, using the \code{.la}
    suffix
  \item A libtool library can designate a static library, a shared
    library, or both.
    \begin{itemize}
    \item \code{--{enable,disable}-{static,shared}} to select
    \end{itemize}
  \item Libtool libraries declared using the \code{LTLIBRARIES}
    primary in a \code{Makefile.am}
  \item Typically used in conjunction with the \code{HEADERS} primary
    to install public headers.
  \item \code{configure.ac} must call the \code{LT_PREREQ} and
    \code{LT_INIT} macros
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Libtool library example}

\begin{block}{configure.ac}
\begin{minted}[fontsize=\small]{bash}
[...]
LT_PREREQ([2.4])
LT_INIT
[...]
\end{minted}
\end{block}

\begin{block}{Makefile.am}
\begin{minted}[fontsize=\small]{make}
bin_PROGRAMS = hello
hello_SOURCES = src/main.c

lib_LTLIBRARIES = libmyhello.la
libmyhello_la_SOURCES = lib/core.c
include_HEADERS = lib/myhello.h
\end{minted}
\end{block}

\end{frame}

\begin{frame}{Libtool versioning}
  \begin{itemize}
  \item Needed to support changes in the library interface
  \item Each system handles library versioning differently
  \item \code{libtool} does not use the traditional
    \code{<major>.<minor>.<revision>}
  \item It uses a more abstract representation, converted differently
    depending on the system on which you're building.
  \item \code{libtool} representation is
    \code{<current>:<revision>:<age>}
    \begin{itemize}
    \item \code{current} is the interface number, incremented whenever
      the public interface changes
    \item \code{revision} is incremented whenever the library source
      code is changed
    \item \code{age} is incremented when new functions are added,
      reset to 0 when functions are removed
    \end{itemize}
  \item Defined using \code{-version-info <current>:<revision>:<age>}
    in \code{<product>_LDFLAGS}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Libtool: demo}

  \begin{center}
    Demo 18
  \end{center}

\end{frame}

\begin{frame}[fragile]{Global {\em automake} variables}

  \begin{itemize}
  \item Variables that you can define in \code{Makefile.am}
    \begin{itemize}
    \item Apply to the current \code{Makefile.am}
    \item Affect all products described in the current \code{Makefile.am}
    \end{itemize}
  \item \code{AM_CPPFLAGS}, default pre-processor flags
  \item \code{AM_CFLAGS}, default compiler flags
  \item \code{AM_LDFLAGS}, default linker flags
  \item \code{LDADD}, libraries not detected by {\em configure} that we
    should link with
  \item Do not set \code{CPPFLAGS}, \code{CFLAGS} and \code{LDFLAGS}, so
    that they can be passed in the environment by users
  \end{itemize}

\begin{block}{Example}
\begin{minted}[fontsize=\tiny]{make}
LDADD = $(top_builddir)/glib/libglib-2.0.la
AM_CPPFLAGS = $(gmodule_INCLUDES) $(GLIB_DEBUG_FLAGS)
AM_CFLAGS = -g
\end{minted}
\end{block}

\end{frame}

\begin{frame}[fragile]{Per product variables}
  \begin{itemize}
  \item \code{<product>_SOURCES}, list of source files
  \item \code{<product>_LDADD}, libraries to link with
  \item \code{<product>_CPPFLAGS}, pre-processor flags, overrides \code{AM_CPPFLAGS}
  \item \code{<product>_CFLAGS}, compiler flags, overrides \code{AM_CFLAGS}
  \item \code{<product>_LDFLAGS}, linker flags, overrides \code{AM_LDFLAGS}
  \end{itemize}

  \begin{block}{Example}
\begin{minted}[fontsize=\tiny]{make}
LDADD = $(top_builddir)/glib/libglib-2.0.la

module_test_LDADD = $(top_builddir)/gmodule/libgmodule-2.0.la $(LDADD)
module_test_LDFLAGS = $(G_MODULE_LDFLAGS)
slice_threadinit_LDADD = $(top_builddir)/gthread/libgthread-2.0.la $(LDADD)
\end{minted}
  \end{block}
\end{frame}

\begin{frame}[fragile]{Useful variables}

  \begin{itemize}

  \item Autoconf provides several variables that can be useful in your
    \code{Makefile.am}:

    \begin{itemize}

    \item \code{top_srcdir}, the relative path to the top of the source tree
    \item \code{srcdir}, the relative path to the directory that contains the current \code{Makefile}
    \item \code{top_builddir}, the relative path to the top of the build tree
    \item \code{builddir}, the current directory
    \item \code{abs_top_srcdir}, \code{abs_srcdir},
      \code{abs_top_builddir}, \code{abs_builddir}, absolute variants
      of the previous variables
    \end{itemize}

  \item Example usage: library code in \code{lib/}, header files in
    \code{include/}:
    \begin{block}{lib/Makefile.am}
    \begin{minted}[fontsize=\scriptsize]{make}
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = ...
libhello_la_CPPFLAGS = -I$(top_srcdir)/include
\end{minted}
\end{block}

  \end{itemize}

\end{frame}

\begin{frame}
  \begin{center}
    Demo 19
  \end{center}
\end{frame}

\begin{frame}[fragile]{Silent rules}

  \begin{itemize}
  \item By default, {\em automake} generate Makefiles that displays
    the full compilation commands
  \item Using the \code{AM_SILENT_RULES}, you can get a slimmer build
    output
  \item By default, the output remains verbose, but can be silenced by
    passing the \code{V=0} variable.
  \item If \code{AM_SILENT_RULES([yes])} is used, the output is quiet
    by default, and verbose if \code{V=1} is passed.
  \end{itemize}

  \begin{block}{}
\begin{minted}[fontsize=\tiny]{console}
$ make
  CC       lib/core.lo
  CCLD     libmyhello.la
  CC       src/main.o
  CCLD     hello
$ make V=1
[...]
libtool: link: (cd ".libs" && rm -f "libmyhello.so.0" && ln -s "libmyhello.so.0.0.0" ...
libtool: link: (cd ".libs" && rm -f "libmyhello.so" && ln -s "libmyhello.so.0.0.0" ...
libtool: link: ar cru .libs/libmyhello.a  lib/core.o
libtool: link: ranlib .libs/libmyhello.a
[...]
\end{minted}
  \end{block}

\end{frame}

\begin{frame}
  \begin{center}
    Demo 20
  \end{center}
\end{frame}

\begin{frame}[fragile]{make dist}

  \begin{itemize}
  \item \code{make dist} generates a tarball to release the software
  \item All files listed in \code{_SOURCES} variables are
    automatically included, as well as the necessary {\em autotools}
    files
  \item Additional files can be added to the distribution using the
    \code{EXTRA_DIST} variable in \code{Makefile.am}:
\begin{block}{Makefile.am}
\begin{minted}[fontsize=\tiny]{make}
# These files are used in the preparation of a release
EXTRA_DIST += \
  PrepareRelease \
  CheckMan \
  CleanTxt \
  [...]
\end{minted}
\end{block}
\item Distribution can also be controlled using the \code{dist} and
  \code{nodist} {\em automake} product modifiers:
\begin{block}{Makefile.am}
\begin{minted}[fontsize=\tiny]{make}
nodist_include_HEADERS += pcrecpparg.h
dist_doc_DATA = doc/pcre.txt
\end{minted}
\end{block}

\end{itemize}

\end{frame}

\begin{frame}[fragile]{Macro directory}

  \begin{itemize}

  \item By default, all the third-party {\em autoconf} macros get
    copied into the (very large) \code{aclocal.m4} file.

  \item It is possible to get some of the third-party macros copied to
    individiual files in a separate directory, which is nicer.

  \item Directory declared using \code{AC_CONFIG_MACRO_DIR}, generally
    named \code{m4} by convention:
    \begin{block}{configure.ac}
      \begin{minted}{bash}
AC_CONFIG_MACRO_DIR([m4])
\end{minted}
\end{block}

\item The \code{ACLOCAL_AMFLAGS} in \code{Makefile.am} should also be
  adjusted:

\begin{block}{Makefile.am}
  \begin{minted}{make}
ACLOCAL_AMFLAGS = -I m4
\end{minted}
\end{block}

\item For now, mainly used by \code{libtool} for its own {\em m4}
  macros.

  \end{itemize}

\end{frame}

\begin{frame}[fragile]{Auxiliary directory}

  \begin{itemize}

  \item The {\em auxiliary files} generated by {\em autotools} such as
    \code{compile}, \code{config.guess}, \code{config.sub},
    \code{depcomp}, etc. are by default in the main directory of the
    source tree.

  \item This clutters the main directory with lots of files, which may
    not be very pleasant.

  \item \code{AC_CONFIG_AUX_DIR} allows to customize where these files
    are generated:
    \begin{block}{configure.ac}
      \begin{minted}{bash}
AC_CONFIG_AUX_DIR([build-aux])
\end{minted}
\end{block}

\item One condition: it must be placed before the calls to
  \code{AM_INIT_AUTOMAKE} and \code{LT_INIT}

  \end{itemize}

\end{frame}

\begin{frame}{Macro/auxiliary directory: demo}
  \begin{center}
    Demo 21
  \end{center}
\end{frame}

\begin{frame}
  \begin{center}
  \Huge
  Questions?\\
  \vspace{1.5cm}
  \huge
  Thomas Petazzoni\\
  \large
  \vspace{0.5cm}
  \code{thomas.petazzoni@bootlin.com}
  \vspace{0.5cm}
  \newline Slides under CC-BY-SA 3.0\\
  \scriptsize
  \url{http://bootlin.com/pub/conferences/2016/elc/petazzoni-autotools-tutorial/}\\
  Demos: \url{https://github.com/tpetazzoni/autotools-demo}
  \end{center}
\end{frame}

\end{document}
