[FE training-materials-updates] slides/autotools-basics: checkpoint progress
Boris Brezillon
boris.brezillon at free-electrons.com
Fri May 22 17:12:36 CEST 2015
Repository : git://git.free-electrons.com/training-materials.git
On branch : mtd-rework-WIP
Link : http://git.free-electrons.com/training-materials/commit/?id=81a06ee7e49fd864051d32cd212351b0442d5bce
>---------------------------------------------------------------
commit 81a06ee7e49fd864051d32cd212351b0442d5bce
Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date: Mon May 18 11:53:55 2015 +0200
slides/autotools-basics: checkpoint progress
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>---------------------------------------------------------------
81a06ee7e49fd864051d32cd212351b0442d5bce
slides/autotools-basics/autotools-basics.tex | 213 ++++++++++++++++++++++++++-
1 file changed, 209 insertions(+), 4 deletions(-)
diff --git a/slides/autotools-basics/autotools-basics.tex b/slides/autotools-basics/autotools-basics.tex
index 44c1750..f6ebcba 100644
--- a/slides/autotools-basics/autotools-basics.tex
+++ b/slides/autotools-basics/autotools-basics.tex
@@ -4,16 +4,15 @@
\begin{itemize}
\item Really a shell script
\item Processed through the \code{m4} preprocessor
- \item Language called \code{m4sh}
\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 do
- most of the usual tests
- \item Make sure to quote arguments to macro with \code{[]}
+ \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}
@@ -259,3 +258,209 @@ config.status: creating testfile
\end{columns}
\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} properly is not easy,
+ especially if you want to:
+ \begin{itemize}
+ \item be portable
+ \item automatically handle dependencies
+ \item support conditional compilation
+ \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}
+
+\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{hello.c} to \code{hello.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}{{\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 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 thing 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}[fragile]{Example: building multiples programs}
+ \begin{block}{Makefile.am}
+ {\small
+\begin{verbatim}
+bin_PROGRAMS = hello test
+hello_SOURCES = main.c common.c common.h
+test_SOURCES = test.c common.c common.h
+\end{verbatim}}
+ \end{block}
+ \begin{itemize}
+ \item Building two programs: \code{hello} and \code{test}
+ \item Shared source files: \code{common.c} and \code{common.h}
+ \end{itemize}
+\end{frame}
+
+\setuplabframe
+{Your first {\em autotools} project}
+{
+ \begin{itemize}
+ \item TODO
+ \end{itemize}
+}
More information about the training-materials-updates
mailing list