Although there are some other alternatives to GNU’s automatic tools, GNU Autotools is still the most widely used in the world for reasons of confidence in the end results. That is, experience has led to this stability.
Unfortunately, there is a lot of obsolete documentation on the internet about Autotools and a lot of complaints about automated tools, so I decided to document a modern and very simplistic test that I created and I will share with you this experience that I made sure to make it as basic as possible. in order to reach understanding.
But still, be sure to display examples that work in larger projects, which by the way the idea is the same, just need a little more attention in the settings.
All topics have been separated with Step by Step and Lists sorted for ease of understanding.
GNU Autotools , also known as the GNU Build System , is a set of programming tools designed to help make source code packages portable to many Unix systems.
It can be difficult to make a software program portable: the C compiler differs from system to system;Some library functions are missing on some systems;Header files may have different names.One way to deal with this is to write conditional code, with code blocks selected using preprocessor directives (#ifdef
);But due to the wide variety of building environments, this approach quickly becomes unmanageable. Autotools is designed to solve this problem more easily.
Autotools is part of the GNU tool chain and is widely used in many open source and open source packages. Its component tools are licensed by free software under the GNU General Public License, with special license exceptions allowing their use with proprietary software.
The GNU Build System makes it possible to create many programs using a two-step process: configure followed by make.
Autotools consists of the GNU Autoconf , Automake, and Libtool utility programs.Other related tools often used alongside it include the GNU make program, GNU gettext , pkg-config, and the GNU Compiler Collection , also called GCC/G ++.
configure.ac
file, run:The files
autoscan-2.69.log
andconfigure.scan
were created.Where the content of autoscan-2.69.log is empty and the content of configure.ac is:
configure.scan
file to configure.ac
:configure.ac
file that has the information: AC_INIT (FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) to your project names, eg AC_INIT (test, 1.0, teste@terminalroot.com .br) .If you wish, use Sed for this, like this:Or use a preferred text editor, for example: Vim . In the end my file looked like this:
configure
script:1 new directory and 1 new file were created:
autom4te.cache/
andconfigure
.Their contents are extensive,configure
for example has 3549 lines .
Makefile.am
File:
And insert this content in:
Makefile.am
file only this time inside the src/
directory:And insert this content in:
Makefile.am
file only this time inside the man/
directory:And insert this content in:
Makefile.am
file only this time inside the scripts/
directory:And insert this content in:
Makefile.am
file only this time inside the doc/
directory:
And insert this content in:
Makefile.am
file only this time inside the examples/
directory:And insert this content in:
autoconf
part with the automake.
Open the
vim configure.ac
file
And insert the content AM_INIT_AUTOMAKE(teste, 1.0) , right after AC_INIT([teste], [1.0], [teste@terminalroot.com.br]) :
If you want it to be easier, just use this command below ( Sed ):
Changing the line that contains: AC_OUTPUT with Sed (if you want to use a text editor and do it manually):
configure
script and Makefile templates:
aclocal.m4
file was generated in the project root directory named:aclocal.m4
Makefile.in
with the argument --add-missing
:
The output will look something similar or the same (if you used the files in this tutorial) to:
Note the line: configure.ac:8: error: required file ‘config.h.in’ not found , if this also appears to you, run:
configure
script:If you want to make sure everything is fine, run ./configure
, make
and test program execution: cd src/ && ./teste
, the output will be: Just a test for Autotools .And if you want to install on the system, run:
Since you have
sudo
installed and are part of the group, otherwisemake install
only work withroot
.
A instalação vai criar alguns diretório e fazer as seguintes cópias dos arquivos para os caminhos:
teste
(regardless of the directory you are in) will get program execution output: Only one test for Autotools ;script-teste.sh
the command: script-teste.sh
(regardless of the directory you are in) will get the output of the program execution: Only a test ;info teste
or man teste
(regardless of the directory you are in) you will get the manual;cat /usr/local/share/doc/teste/README.md
;cat /usr/local/share/doc/teste/my-example-teste.dat
.To uninstall you will need to be in the testes/
directory and run the command:
Absolutely EVERYTHING will be uninstalled, the output will be similar/equal:
If you want to see everything we’ve done here, use pre-made files or run a simple Bash script:
And use the pre-created environment files: gnu-autotools/testes/
or simply run the script that creates the files from scratch: ./gnu-autotools.sh
Or generate everything including Autotools commands via script with the file: ./gnu-autotools-full.sh
In summary GNU Autotools :
autoscan
command attempts to produce a correct configure.ac
file by performing simple parses on package files;autoconf
command produces two files: autom4te.cache
and configure
;autom4te.cache
directory is a directory used to speed up the work of tools, and can be removed when the package is released;configure
file is the shell script that is called by end users.At this point, what the configure file does is just dependency checking as suggested by autoscan , so nothing too conclusive yet;
automake
and autoconf
.automake
generates some “templates” that scripts generated by autoconf
translate into Makefiles.An initial makefile file is required at the root of the package: ./Makefile.am;automake
will take.The “foreign” mode means non-GNU, and is commonly used;Makefile.am
file for each of these directories.automake
will pass one of them home to produce the corresponding Makefile.in
file.These *.in
files will be used by autoconf
scripts to produce the final Makefile
files.+ Usually in the src/Makefile.am
file we define all files that will be created and compiled.In general, uppercase suffixes like “_PROGRAMS” are called primary and partially tell you what to do in your argument;prefixes, in lower case letters (do not have a predefined name) tell the directory where it will be installed.To inform several files, it is used more or less like this:scripts/
usually have the Shell Script that will call the executable, as well as parameter autocomplete (compgen) templates. We use a sample content, but the same would be true (example of the Firefox script):/opt
in its proper directory;aclocal
command creates the tools that generate each script generates the aclocal.m4
file that contains macros for automake
things;automake
command reads configure.ac
and Makefile.a
m, interprets them, and for each Makefile.am
produces a Makefile.in
.The --add-missing
argument tells automake
to provide default scripts for any reported errors, so it can be omitted in future executions;autoreconf
command (used to rectify the lack of config.h.in
) compiles all relevant tools in the correct order and installs missing files.The parameters -f
(assume everything is obsolete and force reconfiguration) and -i
(make a copy of auxiliary files present in the system for your project, call autoheader
).We could still join the -v
parameter by getting -vfi
to see the details of the procedures.autotools
→ autoscan
(configure.scan) → configure.ac
→ autoconf
(autom4te.cache and initial configure) → Makefile.am
( *
) → aclocal
(aclocal.m4) → automake
(Makefile.in) → autoreconf
( config.h.in/header
) → autoconf ( ./configure
) → Makefile
(make && make install)
gnu autotools make language-c cpp