WikiDer > Autoconf

Autoconf
autoconf
Logo
Designer(s)David MacKenzie
EntwicklerDas GNU-Projekt
Veröffentlicht1991
Letzte Version2.69 
(24. April 2012)
BetriebssystemMultiplattform
KategorieCode Generator
LizenzGNU GPL
Versionskontrollegit.savannah.gnu.org
Webseitegnu.org/software/autoconf/
Portal  Portalsymbol  Informatik

GNU AutoConf ist ein Programm, das Konfigurationsskripte für den Aufbau und die Installation von Softwarepakete auf Computern mit einem Betriebssystem, das eine Bourne-Schale ist verfügbar.

Autoconf kennt die für ein Projekt verwendeten Programmiersprachen nicht. Oft wird Autoconf für Projekte verwendet, die in written geschrieben sind C, C , fortran, Erlang oder Ziel c.

Ein Konfigurationsskript konfiguriert ein Softwarepaket für die Installation auf einem bestimmten Zielsystem. Das Softwarepaket kann als Tarball zur Installation auf anderen Betriebssystemen verteilt. Nach einer Reihe von Tests auf dem Zielsystem generiert das Konfigurationsskript Header-Dateien und ein Datei erstellen bevor Sie die Software auf dem Zielsystem installieren. Zusammen mit Auto machen und Lib-Tool bildet Autoconf it GNU-Build-System.

Normalerweise wird der Code für das GNU-Build-System von a . geschrieben IDE erzeugt, wie von Anjuta, die IDE zum Entwickeln GTK Bewerbungen für X11-Desktop-Umgebungen wenn GNOME und Xfce. Anwendungsentwickler braucht die Konfigurationsdateien die von einer IDE generierten werden selten geändert oder modifiziert.

Geschichte

Im Sommer 1991 ist David MacKenzie bei der Free Software Foundation für die Entwicklung der GNUBetriebssystem, begann mit der Entwicklung von Autoconf. In den folgenden Jahren wuchs das System weiter, da verschiedene Autoren das System verbesserten. GNU Autoconf ist schließlich das am weitesten verbreitete Build-Konfigurationssystem für freie oder Open-Source-Software geworden.

Anwendung

Flussdiagramm von autoconf und Auto machen. Die Datei "configure.ac" hieß in früheren Versionen von autoconf "configure.in".

Der Entwickler abonniert GNU-m4 ein Konfigurationsskript namens configure.ac für Autoconf. Dieses Skript besteht aus einer Liste von Anweisungen in Form von m4-Makros. Für die Übersetzung der Anweisungen in . steht eine Bibliothek mit vordefinierten m4-Makros zur Verfügung configure.ac für Anweisungen für ein gewöhnliches Konfigurationsskript. Autoconf wandelt die Anweisungen in den m4-Makros in die tragbarconfigure.acDatei in ein Bourne-Shell-Konfigurationsskript. Autoconf wird nur benötigt, um a . zu erstellen konfigurierenSkript für ein bestimmtes Zielsystem. Normalerweise wird bei einem Softwarepaket nur die Autoconf generiert konfigurierenSkript für die Bourne-Shell enthalten.

Es configure.ac-Datei

Mit dem Dienstprogramm automatischer Scan kann darauf basieren Quellcode Erstellen Sie eine Vorlage für configure.ac.[1] Das Handbuch zu GNU Autoconf rät Entwicklern, die Makros gemäß den Regeln der GNU Coding Standards zu verwenden.[2] Für den Quellcode in der Datei Hallo c mit dem "Hallo Welt"-Programm:

#einschließen<stdio.h>intMain(intargc,verkohlen**argv){druckenf("Hallo Welt!");Rückkehr0;}

erzeugt automatischer Scan von autoconf-2.69 Zum Beispiel a konfigurieren.scan- Datei mit der Vorlage:

# -*- Autoconf -*-# Verarbeiten Sie diese Datei mit autoconf, um ein Konfigurationsskript zu erstellen.AC_PREREQ([2.69])AC_INIT([FULL-PACKAGE-NAME], [AUSFÜHRUNG], [FEHLERBERICHT-ADRESSE])AC_CONFIG_SRCDIR([Hallo c])AC_CONFIG_HEADERS([config.h])# Sucht nach Programmen.AC_PROG_CC# Sucht nach Bibliotheken.# Sucht nach Header-Dateien.# Prüft auf Typedefs, Strukturen und Compiler-Eigenschaften.# Prüft auf Bibliotheksfunktionen.AC_OUTPUT

Die Liste von automatischer Scan generierte Renditen mit Kommentar das Standardformat für die Makroblöcke für die Prüfungen. Diese Datei kann als Grundlage für den Aufbau eines configure.acDatei.

Ansatz

Autoconf ähnelt Metaconfig fürconfig perl. Es ist eng mit dem Imake-System verwandt, das vor der X Window-System (bis X11R6.9) verwendet wurde, hat aber eine andere Philosophie.

Der Autoconf-Ansatz für Software-Portabilität besteht darin, auf Funktionen zu testen, nicht auf Versionen. Der C-Compiler von SunOS 4 unterstützt beispielsweise kein ISO C. Ein Benutzer oder Administrator kann jedoch einen ISO C-kompatiblen Compiler installieren. Ein Versionstest-Ansatz würde das Vorhandensein des ISO-C-Compilers nicht erkennen, aber ein Feature-Test-Ansatz hätte erkannt, dass der Benutzer einen ISO-C-Compiler installiert hatte. Das Grundprinzip dieses Ansatzes besteht darin, die folgenden Vorteile zu erzielen:

  • das Konfigurationsskript kann auf neueren oder unbekannten Systemen zu vernünftigen Ergebnissen führen,
  • es ermöglicht Administratoren, ihre Computer anzupassen und das Konfigurationsskript die Anpassungen zu nutzen.
  • es ist nicht erforderlich, genaue Angaben zu Versionen, Patch-Nummern usw. zu verfolgen, um herauszufinden, ob eine bestimmte Funktion unterstützt wird.

Kritik

Es gibt einige Kritik, weil Autoconf veraltete Technologie verwendet und viele Einschränkungen von früheren Versionen erbt. Das macht das Schreiben eines einfachen configure.ac-Skripts unnötig schwierig, so die Kritiker. Häufig zitierte Schwächen von Autoconf sind:

  • Allgemeine Komplexität der verwendeten Architektur, die meisten Projekte verwenden mehrere Iterationen.[3]
  • Das generierte "configure"-Skript ist für die Bourne-Schale verlangsamt die Makefile-Generierung.
  • Einige Leute denken, dass von autoconf generierte "configure"-Skripte nur eine Befehlszeilenschnittstelle ohne jegliche Standardisierung bieten.[4] Während einige Entwickler gängige Konventionen nicht respektieren, sind solche Konventionen weit verbreitet.[5]
  • M4 ist ungewöhnlich und vielen Entwicklern unbekannt. Daher müssen Entwickler lernen, autoconf mit nicht standardmäßigen Steuerelementen zu erweitern.[4]
  • Eine schwache Abwärts- und Vorwärtskompatibilität erfordert ein Wrapper-Skript.[6]
  • Autoconf-generierte Skripte sind normalerweise groß und ziemlich komplex. Obwohl sie eine umfangreiche Protokollierung erzeugen, bereitet das Debuggen der Skripte immer noch Schwierigkeiten.

Aufgrund dieser Einschränkungen sind einige Projekte, die das GNU-Build-System verwendet haben, auf ein anderes Build-System umgestiegen, wie z CMake und SCons.[3][7]

Externe Links

Verweise