Autoconf

Autoconf
Ontwerper(s)	David MacKenzie
Ontwikkelaar(s)	The GNU Project
Uitgebracht	1991 (32 jaar)
Recentste versie	2.72 (22 december 2023)
Status	Actief
Besturingssysteem	Multiplatform
Geschreven in	m4
Categorie	Codegenerator
Licentie(s)	GNU GPL
Versiebeheer	git.savannah.gnu.org/cgit/autoconf.git ;
Website	(en) Projectpagina
Portaal	Informatica ; Vrije software

GNU Autoconf is een programma waarmee configuratiescripts gegenereerd kunnen worden voor de bouw en de installatie van softwarepakketten op computers met een besturingssysteem waarvoor een Bourne-shell beschikbaar is.

Autoconf is onwetend wat betreft de programmeertalen die voor een project gebruikt zijn. Vaak wordt Autoconf gebruikt voor projecten die zijn geschreven in C, C++, Fortran, Erlang of Objective-C.

Een configuratiescript configureert een softwarepakket voor installatie op een bepaald doelsysteem. Het softwarepakket kan als een tarball verspreid worden voor installatie op andere besturingssystemen. Na het uitvoeren van een reeks tests op het doelsysteem, genereert het configuratiescript headerbestanden en een makefile voor de installatie van de software op het doelsysteem. Samen met Automake en Libtool vormt Autoconf het GNU build systeem.

Gewoonlijk wordt de code voor het GNU build systeem door een IDE gegenereerd, zoals door Anjuta, de IDE voor de ontwikkeling van GTK+-applicaties voor X11-desktopomgevingen als GNOME en Xfce. Applicatieontwikkelaars hoeven de configuratiebestanden die door een IDE gegenereerd zijn zelden te veranderen of aan te passen.

Geschiedenis bewerken

In de zomer van 1991 is David MacKenzie bij de Free Software Foundation voor de ontwikkeling van het GNU besturingssysteem, aan de ontwikkeling van Autoconf begonnen. In de daaropvolgende jaren groeide het systeem voortdurend omdat verschillende auteurs verbeteringen aan het systeem aanbrachten. GNU Autoconf is uiteindelijk uitgegroeid tot het meest gebruikte buildconfiguratiesysteem voor vrije of open-source software.

Toepassing bewerken

Flow diagram van autoconf en automake. Het bestand "configure.ac" heette "configure.in" in eerdere versies van autoconf.

De ontwikkelaar schrijft in GNU m4 een configuratiescript genaamd configure.ac voor Autoconf. Dit script bestaat uit een lijst met instructies in de vorm van m4-macro's. Een bibliotheek van vooraf gedefinieerde m4-macro's is beschikbaar voor de vertaling van de instructies in configure.ac naar instructies voor een gewoon configuratiescript. Autoconf transformeert de instructies in de m4-macro's in het portable configure.ac-bestand naar een configuratiescript voor de Bourne-shell. Autoconf is alleen nodig om een configure-script voor een bepaald doelsysteem te genereren. Meestal wordt met een softwarepakket alleen het door autoconf gegenereerde configure-script voor de Bourne-shell meegeleverd.

Het `configure.ac`-bestand bewerken

Met het hulpprogramma autoscan kan op basis van broncode een sjabloon gegenereerd worden voor configure.ac.^[2] De GNU Autoconf handleiding adviseert ontwikkelaars om de macro's volgens de regels van de GNU Coding Standards te gebruiken.^[3] Voor de broncode in het bestand hallo.c met het "Hallo wereld"-programma:

#include <stdio.h>

int main(int argc, char **argv) {
	printf("Hallo wereld!\n");
	return 0;
}

genereert autoscan van autoconf-2.69 bijvoorbeeld een configure.scan-bestand met het sjabloon:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.69])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([hallo.c])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_OUTPUT

De lijst die door autoscan gegenereerd wordt geeft met commentaar de standaardindeling voor de blokken met macro's voor de controles aan. Dit bestand kan als basis dienen voor de opbouw van een configure.ac-bestand.

Benadering bewerken

Autoconf is vergelijkbaar met Metaconfig voor Perl. Het is nauw verwant aan het imake-systeem dat vroeger voor het X Window System (tot X11R6.9) werd gebruikt, maar heeft een andere filosofie.

De Autoconf benadering van softwareportabiliteit is om te testen op functies, niet op versies. De C-compiler van SunOS 4 ondersteunt bijvoorbeeld geen ISO C. Het is echter mogelijk dat een gebruiker of beheerder een ISO C-compliant compiler installeert. Een benadering door het testen van versies zou de aanwezigheid van de ISO C compiler niet detecteren, maar een benadering met het testen van functies zou ontdekt hebben dat de gebruiker een ISO C compiler geïnstalleerd had. De grondgedachte van deze aanpak is bedoeld om de volgende voordelen te behalen:

het configure script kan redelijke resultaten opleveren op nieuwere of onbekende systemen,
het stelt beheerders in staat om hun machines aan te passen en het configure script te laten profiteren van de aanpassingen,
het is niet nodig kleinste details van versies, Patch nummers, enz. bij te houden om erachter te komen of een bepaalde functie wordt ondersteund.

Kritiek bewerken

Er is enige kritiek omdat Autoconf gedateerde technologie gebruikt en veel beperkingen erft van eerdere versies. Daardoor wordt het schrijven van een eenvoudig configure.ac script volgens de critici onnodig bemoeilijkt. Vaak aangehaald zwakke punten van Autoconf zijn:

Algemene complexiteit van de gebruikte architectuur, de meeste projecten gebruiken meerdere herhalingen.^[4]
Het gegenereerde "configure"-script is geschreven voor de Bourne-shell waardoor de generatie van de Makefile traag verloopt.
Sommige mensen denken dat "configure"-scripts die door autoconf zijn gegenereerd alleen een command-line interface opleveren, zonder enige standaardisatie.^[5] Hoewel sommige ontwikkelaars geen gemeenschappelijke conventies respecteren, worden dergelijke overeenkomsten wel veel gebruikt.^[6]
M4 is ongebruikelijk en onbekend voor veel ontwikkelaars. Daarom moeten ontwikkelaars leren om autoconf uit te breiden met niet-standaard controles.^[5]
Zwakke achterwaartse en voorwaartse compatibiliteit vereist een wrapperscript.^[7]
Autoconf gegenereerde scripts zijn meestal groot en nogal complex. Hoewel ze uitgebreide logging produceren levert het debuggen van de scripts nog steeds moeilijkheden op.

Als gevolg van deze beperkingen zijn een aantal projecten die het GNU Build System gebruikten overgeschakeld op een ander buildsysteem, zoals CMake en SCons.^[4]^[8]

Externe links bewerken

(en) Projectpagina
(en) GNU Autoconf macro archive
(en) The Goat Book homepage (aka the Autobook)
(en) Using Automake and Autoconf with C++ (gearchiveerd)
(en) Using C/C++ libraries with Automake and Autoconf.
(en) Autotoolset home page
(en) Autotools: A practitioner's guide to Autoconf, Automake and Libtool
(en) Autotools Mythbuster

Bronnen, noten en/of referenties

↑ Zachary Weinberg, autoconf-2.72 released [stable] (22 december 2023). Geraadpleegd op 25 december 2023.
↑ (en) Autoconf manual. Gearchiveerd op 2 januari 2022.
↑ (en) GNU Coding Standards. Gearchiveerd op 2 januari 2022.
↑ ^a ^b Neundorf, Alexander, Why the KDE project switched to CMake -- and how (21 juni 2006). Gearchiveerd op 20 november 2021.
↑ ^a ^b McCall, Andrew, Stop the autoconf insanity! Why we need a new build system (21 juni 2003). Gearchiveerd op 28 oktober 2011.
↑ GNU Coding Standards. Gearchiveerd op 7 december 2021.
↑ Dickey, Thomas, why i still use autoconf 2.13. Gearchiveerd op 26 oktober 2021.
↑ https://web.archive.org/web/20081202083359/http://www.blender.org/development/release-logs/blender-233/build-systems/

[wikidata-884f26b1b868e6637349e35e886f477c02f54ef2-v3-1] Zachary Weinberg, autoconf-2.72 released [stable] (22 december 2023). Geraadpleegd op 25 december 2023.

[2] (en) Autoconf manual. Gearchiveerd op 2 januari 2022.

[3] (en) GNU Coding Standards. Gearchiveerd op 2 januari 2022.

[kde-4] Neundorf, Alexander, Why the KDE project switched to CMake -- and how (21 juni 2006). Gearchiveerd op 20 november 2021.

[stop-insanity-5] McCall, Andrew, Stop the autoconf insanity! Why we need a new build system (21 juni 2003). Gearchiveerd op 28 oktober 2011.

[gnu-coding-6] GNU Coding Standards. Gearchiveerd op 7 december 2021.

[autoconf_2.13-7] Dickey, Thomas, why i still use autoconf 2.13. Gearchiveerd op 26 oktober 2021.

[blender-8] ttps://web.archive.org/web/20081202083359/http://www.blender.org/development/release-logs/blender-233/build-systems/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]