GNU Autotools I - Introduction

First thing first: what are GNU Autotools, and what are they used for? The moniker "GNU Autotools" refers to a collection of software packages: Autoconf, Automake and Libtool. These packages include programs aimed at standardizing and automating the build, test, release and installation processes across multiple platforms. In that sense, it shares a lot of goals and purpose with other tools such as CMake. Most of the GNU software is built using Autotools; git is a famous example.

More specifically, what the Autotools do is generate configure scripts and Makefiles from certain configuration files. When generating these files, portability across different platforms is considered in order to allow the package to be built in as many different environments as possible.

A user's perspective

In this context, we will consider a user a person who downloaded a source tarball for some package, and wants to build it and install it in his system. Across the years, certain patterns have emerged in the way users build and install GNU packages. The Autotools have captured and automated many of these conventions. To begin with, the first thing the user should do after decompressing the tarball, is look for an INSTALL file in the root directory of the extracted files. This will consist of a text file with detailed instructions for configuring, building and installing the package in question. Except for very specific cases that deviate from the norm, these steps will involve running the following commands in a terminal: 


./configure
make
sudo make install

The first step runs the configure script, which examines the environment it's running in to ensure it has all the features it needs to build the package. This can include a number of things and will vary per package, but typical requirements are the m4 macro processor and a C++ compiler like gcc. When running this script, its output will consist of two sections:

  • The first part contains lines starting with "checking": this will display yes/no for the features it was programmed to check for. At this step, the script can fail due to a mandatory feature missing. In order to continue, these fatal errors need to be addressed, typically by installing the required package.
  • The second part contains lines starting with "config.status". These are generated by an ancillary script, and they indicate the files that are generated for building the package: Makefiles, config.h and more. We'll look at this in more detail later.

The second step, make, uses the files generated by the configure step to drive the build process and generate the binaries from the source code. Since the configure script's goal is to ensure the success of make, it's unlikely to encounter errors at this step. If these do appear, they will be package-specific, and if googling doesn't yield a solution, contacting the package maintainers is the recommended course of action.

Finally, the third step, which may require root privileges (hence the sudo), copies the generated binaries to a predefined location in order to effectively install the package. This is, by default, /usr/local/bin. To install to a different location, including ones that do not require root privileges, the user can pass the --prefix option to the configure script.

Between the make and install steps, optionally, some packages offer the possibility of running a test suite in order to ensure the programs work fine before proceeding with installation. The way to do is expected to be specified in the INSTALL file, and it is usually the make check command.

The actual tools

Let's abandon user land and go back to developer land. What are the actual programs that comprise the Autotools suite, and what does each of them do?

  • Autoconf: Generates the configure and testsuite scripts. Given configuration files as input, it will generate both scripts as output.
  • Automake: Simplifies the process of generating Makefiles.
  • Libtool: Provides an abstraction for the portable creation of shared libraries.

The best use case for Autotools is when building software targeting Unix/Linux systems. This also includes POSIX-compliant systems such as Cygwin running under Windows, or Mac OS from version 10 (Leopard) onwards. The programming languages for which Autotools provides native support are, at the time of this writing (March 2023):

  • C
  • C++
  • Objective C
  • Objective C++
  • Fortran
  • Fortran 77
  • Erlang
  • Go

What "native support" for a language means is that Autonconf can compile, link and run source-level feature checks for projects built with that language. It is possible to use Autotools for, say, a Java project, but there won't be M4 macros available for managing the configure step for a Java project. Autotools are extensible, so it is quite viable to add support for any language, if deemed necessary.

Comments

Post a Comment

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce
Keep reading