These two files are mostly seen in open source projects.
What are they for, and how do they work?
Makefile.am is a programmer-defined file and is used by automake to generate the Makefile.in file (the .am stands for automake).
The configure script typically seen in source tarballs will use the Makefile.in to generate a Makefile.
The configure script itself is generated from a programmer-defined file named either configure.ac or configure.in (deprecated). I prefer .ac (for autoconf) since it differentiates it from the generated Makefile.in files and that way I can have rules such as make dist-clean which runs rm -f *.in. Since it is a generated file, it is not typically stored in a revision system such as Git, SVN, Mercurial or CVS, rather the .ac file would be.
Read more on GNU Autotools.
Read about make and Makefile first, then learn about automake, autoconf, libtool, etc.
Simple example
Shamelessly adapted from: http://www.gnu.org/software/automake/manual/html_node/Creating-amhello.html and tested on Ubuntu 14.04 Automake 1.14.1.
Makefile.am
SUBDIRS = src
dist_doc_DATA = README.md
README.md
Some doc.
configure.ac
AC_INIT([automake_hello_world], [1.0], [bug-automake#gnu.org])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_CC
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([
Makefile
src/Makefile
])
AC_OUTPUT
src/Makefile.am
bin_PROGRAMS = autotools_hello_world
autotools_hello_world_SOURCES = main.c
src/main.c
#include <config.h>
#include <stdio.h>
int main (void) {
puts ("Hello world from " PACKAGE_STRING);
return 0;
}
Usage
autoreconf --install
mkdir build
cd build
../configure
make
sudo make install
autotools_hello_world
sudo make uninstall
This outputs:
Hello world from automake_hello_world 1.0
Notes
autoreconf --install generates several template files which should be tracked by Git, including Makefile.in. It only needs to be run the first time.
make install installs:
the binary to /usr/local/bin
README.md to /usr/local/share/doc/automake_hello_world
On GitHub for you to try it out.
DEVELOPER runs autoconf and automake:
autoconf -- creates shippable configure script
(which the installer will later run to make the Makefile)
‘autoconf’ is a macro processor.
It converts configure.ac, which is a shell script using macro instructions, into configure, a full-fledged shell script.
automake - creates shippable Makefile.in data file
(which configure will later read to make the Makefile)
Automake helps with creating portable and GNU-standard compliant Makefiles.
‘automake’ creates complex Makefile.ins from simple Makefile.ams
INSTALLER runs configure, make and sudo make install:
./configure # Creates Makefile (from Makefile.in).
make # Creates the application (from the Makefile just created).
sudo make install # Installs the application
# Often, by default its files are installed into /usr/local
INPUT/OUTPUT MAP
Notation below is roughly: inputs --> programs --> outputs
DEVELOPER runs these:
configure.ac -> autoconf -> configure (script) --- (*.ac = autoconf)
configure.in --> autoconf -> configure (script) --- (configure.in depreciated. Use configure.ac)
Makefile.am -> automake -> Makefile.in ----------- (*.am = automake)
INSTALLER runs these:
Makefile.in -> configure -> Makefile (*.in = input file)
Makefile -> make ----------> (puts new software in your downloads or temporary directory)
Makefile -> make install -> (puts new software in system directories)
"autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of M4 macro calls."
"automake is a tool for automatically generating Makefile.in files compliant with the GNU Coding Standards. Automake requires the use of Autoconf."
Manuals:
GNU AutoTools (The definitive manual on this stuff)
m4 (used by autoconf)
autoconf
automake
Free online tutorials:
Using GNU Autotools
Example:
The main configure.ac used to build LibreOffice is over 12k lines of code, (but there are also 57 other configure.ac files in subfolders.)
From this my generated configure is over 41k lines of code.
And while the Makefile.in and Makefile are both only 493 lines of code. (But, there are also 768 more Makefile.in's in subfolders.)
reference :
Makefile.am -- a user input file to automake
configure.in -- a user input file to autoconf
autoconf generates configure from configure.in
automake gererates Makefile.in from Makefile.am
configure generates Makefile from Makefile.in
For ex:
$]
configure.in Makefile.in
$] sudo autoconf
configure configure.in Makefile.in ...
$] sudo ./configure
Makefile Makefile.in
Related
When compiling a project that comes with bash configure scripts such as: autogen.sh, makefile.am, configure.ac, configure.in etc. Where does compiling takes place, if you invoke these commands:
autogen.sh
autoconf configure.ac
...
...
./configure
make
make install
Does the compiling happens before the "make install"? or at "make install". I am only interested
in compiling the library so that my code can compile rather than to actually install the software.
Usually, configure prepares the Makefiles, make compiles everything and make install copies the binaries into the appropriate folders on your system.
I wanted to know why autoconf and automake (auto tools) are used to Build the Gstreamer(and odes like gstramer).
These I suppose are used to generate the Makefiles which then can be used by simply running make command.
What are makefile.am and configure.ac files .
Rgds,
Softy
Makefile.am is an Automake script shorthand for writing makefiles. It's processed by Automake to generate Makefile.in. It's easier to use Automake language to specify dependencies and standard targets required by the GNU Build System.
Makefile.in is a makefile that is missing platform-dependent code. See below.
configure.ac is a file, written in the M4 macro language. It is processed by Autoconf to generate a shell script called configure. It is much easier and less error-prone to write configure.ac than writing a 200k shell script.
configure is a shell script that checks whether your platform supports all sorts of portable and nonportable features. It generates a whole bunch of files. It can also put platform-dependent and system-dependent code into files (usually ending with *.in), transforming them into the same file without the .in extension. Specifically, it generates Makefile from Makefile.in.
The flow diagram on this Wikipedia page may be helpful.
I have a program and I want to measure it performance but using gprof.now I want to add a -pg flag in it. I have many different files makefile.am makefile.in configure
I install the program using following steps
./configure
make
make install
Now I have read somewhere that:
automake gererates Makefile.in from Makefile.am
configure generates Makefile from Makefile.in
I am totally confused and want to ask two question
In which file and where do I add -pg flag? In makefile.in or makefile.am as they both have different types of flag options?
If configure generates makefile from makefile.in and automake generates makefile.in from makefile.am then shoud'nt we be using make before ./configure? what the hierarchy?
man gcc:
-pg Generate extra code to write profile information suitable for the
analysis program gprof. You must use this option when compiling
the source files you want data about, and you must also use it when
linking.
It says it needs to be in CPPFLAGS (used for both C and C++ code) and LDFLAGS (unless non-standard variables are used). The standard way is to pass flags to configure script:
$ ./configure CPPFLAGS=-pg LDFLAGS=-pg
I have a project with autotools: automake, autoconf.
I want to prohibit make from remaking files configure, Makefile.in, etc; just to do compile job.
Some of files are edited by hand, and I know that I should not to do this. (Or the project was updated from CVS with all generated files stored in CVS).
But at the moment I have no correct version autotools installed.
What must be modification times of this files (which must be newer/older):
aclocal.m4
configure.in
confdb/ax_prefix_config_h.m4
Makefile.am
Makefile.in
Makefile
configure
config.status
Or: what sequence of touch commands must I do to achieve my goal?
First of all, if you edit a generated file directly, it wouldn't be rebuilt anyway, because it is then newer then its prerequisites.
Then, there are two separate things going on here: config.status and Makefile are created during the build. It's hard to prevent these from being remade during the build unless you make their timestamps newer.
The other files are generated by the various autotools. Recent versions of Automake do not create rules by default that remake them automatically. Depending on your package, you might want to use the configure option --disable-maintainer-mode. The Automake documentation contains some more interesting information about that option.
One trick I sometimes use with a package that I don't know much about or that has a pretty messed up build system is to run something like
make all AUTOCONF=: AUTOHEADER=: AUTOMAKE=: ACLOCAL=:
so that if these programs happen to be called, a noop would be substituted.
touch confdb/*.m4
touch configure.in
touch *.m4
touch *.am
touch Makefile.in */Makefile.in
touch *config.h.in */*config.h.in
touch configure
touch config.status
touch config.h
touch Makefile
Problems with automake & cvs are described here http://www.gnu.org/s/hello/manual/automake/CVS.html
Try to explicitly tell make those files should not be remade, via command-line
$ make -o configure -o Makefile.in
or by using MAKEFLAGS
$ MAKEFLAGS="-o configure -o Makefile.in" make
The excerpt from GNU make's manual
‘-o file’
‘--old-file=file’
‘--assume-old=file’
Do not remake the file file even if it is older than its prerequisites, and do not remake
anything on account of changes in file. Essentially the file is treated as very old and
its rules are ignored. See Avoiding Recompilation of Some Files.
If yours autotools template correctly uses $(MAKE) for subdirs, there should be no problems.
I have seen both in different things I have configured. What I the difference? Is it notable to use only one? Or does it not matter which one to use?
configure.ac and configure.in are two possible names for the master Autoconf source file, which is processed by autoconf to generate the configure shell script. configure.ac is preferred for new packages, configure.in is an older name which still works. (The .in suffix is now recommended to be used only for files which will be processed by config.status, which is the result of running configure.)
Makefile.am is an Automake source file. Automake processes it and generates Makefile.in, which is then further processed by config.status to generate the final Makefile. An Automake-generated Makefile.in is not meant to be edited by hand. However, if a project doesn't use Automake (but does use Autoconf), then it will only have a Makefile.in which is hand-edited.
For further details see http://www.gnu.org/software/autoconf/manual/html_node/Making-configure-Scripts.html - particularly the diagrams.