GNU Build System

from Wikipedia, the free encyclopedia
Program flow chart for autoconf and automake , two tools in the GNU Build System

The GNU Build System is a collection of programming tools developed by the GNU Project . These tools are for the porting of source code - packages on Unix thought systems. The GNU Build System is part of the GNU Toolchains and is widely used in free software projects. While the tools themselves are free software and are under the GPL , proprietary projects can also be developed with them.

Tools included

The GNU Build System is created using the so-called Autotools . Autotools contains the GNU tools Autoconf , Autoheader , Automake and Libtool . Other similar programs that are often used with the GNU Build System are GNU Make , GNU gettext , pkg-config, and the GNU Compiler Collection , also known as GCC.

GNU Autoconf

Autoconf is a software that automatically shell scripts generated, which in turn Makefiles create a software package to the translation of the source code for various Unix systems (such as Linux allow). The scripts created by Autoconf can run alone and do not require Autoconf.

Autoconf uses GNU m4 to create a portable shell script called configure from a user-created configuration file configure.ac . This configure script runs without further user intervention and generates headers and makefiles from ready-made templates that are adapted to the system environment .

Autoconf was developed by David MacKenzie in 1991 to simplify his work at the Free Software Foundation . In the following years its importance grew and it is now the most widely used configuration system for portable open source software .

Autoconf processes files ( configure.inor configure.ac, although configure.acgenerally preferred) to generate a configuration script .

If the generated configuration script is executed, Makefile.inthe final files are generated - if they have been specified - from templates (which normally have the ending ".in" (e.g. )), in this case a Makefile.

Autoconf is used to iron out minor incompatibilities that have been found in various Unixoid operating systems. For example, some Unix systems have tools that are known to be inoperable or completely absent. Autoconf creates a shell script which can recognize and work around this. The output of the Autoconf tool is the configuration script.

Autoconf includes some utilities that have been developed to enable the generation of configure.ac easier, including the car header tool that is used to C - header files to handle, auto scan, which generates an initial file for Autoconf and ifnames, which contains the C preprocessor identifier used in the program.

Working method

Autoconf works in a similar way to the Perl meta configuration package .

The idea behind autoconf is to check the availability of properties, not of specific program versions. For example, supports the C compiler from SunOS not 4 the ISO C standard. A pure version-based approach would therefore not find an ISO-C compiler, although a corresponding compiler could definitely be available on this system. Only the approach of checking a target system for certain properties (features) leads to the desired result.

Usually a portable script called “configure” is generated by the configure.ac file . Before compiling the source code, this script must be executed in order to generate the system-dependent makefiles and header files and to check the system requirements. If the "configure" script is executed with the "--help" argument , the possible options are displayed.

GNU autoheader

GNU Autoheader creates a template for a configuration header file from an Autoconf configuration file. The use of GNU Autoheader is optional. GNU Autoconf or Automake can also be used without GNU Autoheader. If Autoheader is not used, the configuration macros required by the project must be transferred as parameters for each compiler call. So if autoheader is not used and the project requires a large number of configuration macros, the screen output of compiler calls can become confusing.

GNU automake

Automake helps create portable files Makefilesthat make can process in sequence. It gets its input as Makefile.amand converts it to a Makefile.infile that is used by the "configure" script Makefileto generate the final one.

GNU Libtool

Libtool helps to create static and dynamic libraries in different Unix-like operating systems. Libtool does this by abstracting the library creation process, hiding differences between different systems ( e.g. GNU / Linux systems and Solaris ).

Benefits of the GNU Build System

The GNU Build System provides a programmer with an environment with which he can program cross-platform software (which can at least be executed on different Unix-like operating systems ). It also simplifies the build process because the user normally only has to execute a few commands to generate and install the program from the source code .

The tools used by the GNU Build System only need to be available on the developer's computer. The users themselves do not need an installed version of Autoconf, Automake or Libtool in order to create or install the software that was created with their help. This makes the GNU Build System independent because it only needs standard tools to build, which are available on all Unix systems. This is done through the use of Unix shell scripts , which help to configure the program for the operating system of the respective user.

The tools used in the GNU Build System can be used individually or collectively; for example, a software project can use Autoconf without also using Automake. However, the components of the GNU Build System can also interact with each other.

  • Usable configure scripts also arise on very new or completely unknown target systems
  • The best result (size, speed, stability) for the target system can be achieved through parameters
  • Normally, no exact software version specifications are required for translating the sources, only certain system properties

Limitations of the GNU Build System

The GNU Build System uses Bourne-compatible shell scripts to aid the user with configuration and the build process. However, some operating systems, such as the Windows family , cannot run Bourne shell scripts on their own. This makes building software on the Windows operating system a bit more difficult than building on Unix , which have Bourne shell script support implemented by default.

To implement compatibility with configuration scripts, one can install the Cygwin system. Cygwin also supplies the GNU Compiler Collection , GNU Make, and other software that creates an almost complete Unix-like system in Windows. With MinGW , cross-compiling is increasingly enabled in order to create software for a Windows host from a GNU / Linux or other Unixoid build system.

Projects using the GNU Build System can optionally provide a configuration script in their software configuration management systems (such as CVS or Subversion ). If a project using the GNU Build System does not ./configureprovide a generated script for all users, the user has to generate one. One possible way to do this is to run a series of commands on a shell command line: 

$ aclocal
$ autoconf
$ autoheader
$ automake --add-missing

Not all or more commands may be required, depending on how the existing project uses the GNU Build System . Additionally, it is also common practice to provide a script, often named as autogen.sh, that executes all of the mentioned pre-build tools. In some cases you can too 

$ autoreconf

that automatically calls the commands mentioned if they are needed.

Discussion of disadvantages and criticism

  • Even if autoconf / automake / libtool / m4 /… -based build systems are to increase portability, this approach all too often does not work as desired; especially non-Linux builds and cross-builds require a lot of additional work and adjustments.
  • For cross-builds, the configuration scripts must be executed on the target system or a cross-compilation-capable system; this is often not possible, or only possible with great difficulty, if the script and the files required for its creation are not supplied and can mean a lot of additional work.
  • Adjustments are time-consuming and error-prone due to the M4 macro language, which many developers are not sure of, and the confusing structure.
  • Libtool-based builds take much longer than simple make-builds for a certain system, since libtool builds all libraries multiple times by default (shared, static, sometimes even optimized and debug version already during the development cycle), so that development turnaround cycles can take significantly longer with the default settings than with other systems. The overhead of macro and shell calls can also be significant on some non-Linux systems.
  • In the past, different versions of autoconf / automake / libtool / etc. not compatible with each other; Several versions therefore had to be installed and managed on the development system, or configure / Makefile input files required constant adjustments with new versions.
  • The KDE team has not used autoconf / automake / libtool / etc since KDE4. and uses CMake in its place . Other projects also began evaluating alternative build systems. Ant and JAM are other approaches. Integrated development environments (IDE) often contain their own build systems. B. can be configured by CMake.

See also

literature

  • Florian Stöhr: The GNU Autotools: Guide for software distribution. C&L Computer & Literaturverlag, Böblingen 2007, ISBN 978-3-936546-48-4
  • John Calcote: Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool. No Starch Press, Daly City, California 2010, ISBN 978-1593272067

Web links

Individual evidence

  1. ^ GNU Build System (automake). Retrieved March 22, 2018 .
  2. ↑ Autoconf , “Writing configure.ac”
  3. ↑ http://www.seul.org/docs/autotut/#autoheader