GNU Build System

The GNU build system, also known as Autotools, is a suite of tools for computer programming, developed by the GNU project. These tools are intended for porting source packages on Unix systems. The GNU build system is part of the GNU toolchains and is widely used in free software projects. While the tools are free software and is published under the GPL and proprietary projects can be developed with it.

Included Tools

The GNU Build System contains the GNU tools Autoconf, Automake, headers, Automake and Libtool. Other similar programs, which are often used in conjunction with the GNU build system, GNU Make, GNU gettext are, pkg- config and the GNU Compiler Collection, also known as GCC known.

GNU Autoconf

Autoconf is a software that automatically generates shell scripts, which in turn create makefiles for a software package to enable the compilation of the source code for various UNIX systems (such as Linux). The scripts of autoconf are alone executable and do not require Autoconf.

Autoconf uses GNU m4 to from a user-created configuration file configure.ac a portable shell script called configure to generate. This configure script runs without any additional user intervention and generates the system environment customized headers and makefiles from ready-made templates.

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

Autoconf processed files ( configure.in or configure.ac, although configure.ac is generally preferred ) to generate a configuration script.

If the generated configuration scripts executed - to the extent they have been given - from templates ( usually with an extension (eg Makefile.in ) have " in. " ), The final files are generated, in this case a Makefile.

Autoconf is used to iron out minor incompatibilities that were found in various Unix-like operating systems. For example, some Unix-like systems aids, which are known as non-functional or missing completely. Autoconf creates a shell script which can detect and work around this. The output of the autoconf tool is the configuration script.

Autoconf contains some utility programs that have been developed to simplify the generation of configure.ac, including the car header tool that is used to handle C header files, auto scan, which produces and ifnames an initial file for autoconf which the contains carbon Präprozessoridentifier used in the program.

Operation

Autoconf works comparable to the Metakonfigurationspaket of Perl.

The idea behind is the autoconf check for the availability of properties, not of specific program versions. Thus, for example, supports the C compiler of SunOS 4 is not the ISO C standard. A pure version based approach would therefore find no ISO C compiler, although quite a corresponding compiler could be present on this system. Only the approach of a target system to be checked for certain properties (features), here leads to the desired result.

Normally the configure.ac file a portable script called "configure" generated. Before compiling the source code of this script must be run to generate the system-dependent makefiles and header files and check the conditions of the system. If the "configure " script with the "- help " argument runs, the available options are displayed.

GNU Automake header

GNU Automake header creates a template for a configuration header file from an autoconf configuration file. The use of GNU Automake header is optional. GNU Autoconf and Automake can also be used without GNU car header. If Auto header is not used, then the time required by the project configuration macros must be passed as a parameter with each compiler invocation. So can when not in use by autoheader, if the project requires a large number of configuration macros, screen output of compiler calls are confusing.

GNU Automake

Automake helps in the production of portable makefiles that are processed in order of make. It receives its input as Makefile.am and converts it into a Makefile.in file, which is used by the "configure " script to generate the final Makefile.

GNU Libtool

Libtool helps when creating static and dynamic libraries for various Unix-like operating systems. Libtool does this by abstracting the creation process of the library, while it hides differences between different systems (eg GNU / Linux and Solaris systems ).

Advantages of the GNU Build System

The GNU build system provides a programmer an environment with which he can write cross -platform software (which can be running at least on various Unix-like operating systems). It also simplifies the build process because the user usually needs to run a few commands to create the program from the source code and install it.

The tools that are used by the GNU build system, have to be present only on the developer's computer. The users themselves do not require any installed version of Autoconf, Automake, Libtool, or to create or to install, which was produced with the help of the software. This makes the GNU build system independent, because it needs to create only standard tools, which are available on all Unix-like systems. This is accomplished through the use of shell scripts that help to configure the program for the operating system of the respective user.

The tools that are used in the GNU build system can also be used individually or together; For example, a software project Autoconf use without also use Automake. However, the components of the GNU build system can also interact with each other.

• Recyclable configure scripts also occur on very new or completely unknown target systems
• Through parameter can be a best result for the target system (size, speed, stability ) can be achieved
• Usually no exact software version requirements for the translation of the sources are provided, but only certain system properties

Limitations of the GNU build system

The GNU build system uses Bourne compatible shell script to help the user in the configuration and build process. However, some operating systems such as Microsoft Windows product line, Bourne shell scripts can not run alone. This makes creating software with the Windows operating system a bit more difficult than building on Unix-like, which have a standard implementation support for Bourne shell scripts.

To implement compatibility with configuration scripts, you can install the Cygwin system. Cygwin also provides the GNU Compiler Collection, GNU Make, and other software that creates an almost complete unixoides system in Windows. Increasingly also cross-compiling with MinGW is made ​​possible to run a Windows host from a GNU / Linux or other Unix-like build systems. Since the dawn of MSYS the use of Cygwin is less necessary when using the MinGW toolkit, as it aims to integrate the Autotools creates an environment that is largely POSIX - compatible.

Projects that use the GNU build system, you can optionally Configuration Management provide a configuration script in their software systems (such as CVS or Subversion). If a project that uses the GNU build system, not generated. / Configure file for all user provides, the user must generate a. One possible way to accomplish this is to perform a series of commands in a shell command line is:

$ aclocal $ autoconf $ Autoheader $ Automake It may not be all or several commands needed, depending on the manner in which the existing project uses the GNU build system. In addition, it is also common to provide a script available, often designated as autogen.sh which performs all of said pre-build tool. In some cases it is also possible

$ autoreconf use that automatically calls the specified commands when they are needed.

Discussion of drawbacks and criticism

• Even if autoconf/automake/libtool/m4 / ...- based build systems are designed to increase the portability, so this procedure too often does not work as desired; not just Linux builds and builds cross- require much additional work and adjustments.
• For cross- builds the configuration scripts must be generated on the target system; this is often not, or only much more complicated and can mean a very high additional expense.
• Adjustments are due to the many developers not sure dominated M4 macro language and the confusing structure, consuming and error-prone.
• Libtool -based builds take much longer than a simple make- builds for a particular system, since libtool by default all libraries multiple builds (shared, static, sometimes even optimized and debug version already during the development cycle ), so that development turnaround Cycles can take with the default settings significantly longer than with other systems. Even the overhead of macro - and shell calls can be significantly on some non-Linux systems.
• In the past, various autoconf / automake / libtool / etc versions are not compatible with each other; on the development system therefore had to be installed and managed multiple versions, or configure / Makefile input files required constant adjustments with new versions.
• The KDE team waived since KDE4 on autoconf / automake / libtool / etc and used in its place CMake. Other projects began with the evaluation of alternative build systems. Ant and JAM are other approaches. Integrated Development Environments (IDE ) often have their own build systems that can be configured, for example CMake.