GNU Build System - Versionsgeschichte

2001:9E8:6C63:2E01:3D9A:AD77:A542:EF8B: /* Diskussion von Nachteilen und Kritik */ Zeichensetzung und so

2025-04-17T12:57:16Z

Diskussion von Nachteilen und Kritik: Zeichensetzung und so

← Nächstältere Version		Version vom 17. April 2025, 14:57 Uhr
Zeile 70:		Zeile 70:
	== Diskussion von Nachteilen und Kritik ==		== Diskussion von Nachteilen und Kritik ==
	* Selbst wenn autoconf/automake/libtool/m4/…-basierte Build-Systeme die Portabilität erhöhen sollen, so funktioniert diese Vorgehensweise allzu oft nicht wie gewünscht; gerade Nicht-Linux-Builds und Cross-Builds erfordern viel zusätzliche Arbeit und Anpassungen.		* Selbst wenn autoconf/automake/libtool/m4/…-basierte Build-Systeme die Portabilität erhöhen sollen, so funktioniert diese Vorgehensweise allzu oft nicht wie gewünscht; gerade Nicht-Linux-Builds und Cross-Builds erfordern viel zusätzliche Arbeit und Anpassungen.
	* Für Cross-Builds müssen die Konfigurationsscripte auf dem Zielsystem oder einem Cross-Compilation fähigen System ausgeführt werden; dies ist oft nicht, oder nur sehr umständlich möglich, wenn das Script und die zu seiner Erstellung erforderlichen Dateien nicht mitgeliefert werden und kann einen sehr hohen zusätzlichen Aufwand bedeuten.		* Für Cross-Builds müssen die Konfigurationsscripte auf dem Zielsystem oder einem Cross-Compilation-fähigen System ausgeführt werden; dies ist oft nicht oder nur sehr umständlich möglich, wenn das Script und die zu seiner Erstellung erforderlichen Dateien nicht mitgeliefert werden und kann einen sehr hohen zusätzlichen Aufwand bedeuten.
	* Anpassungen sind, aufgrund der von vielen Entwicklern nicht sicher beherrschten M4-Makro-Sprache und der unübersichtlichen Struktur, aufwendig und fehlerträchtig.		* Anpassungen sind aufgrund der von vielen Entwicklern nicht sicher beherrschten M4-Makro-Sprache und der unübersichtlichen Struktur aufwendig und fehlerträchtig.
	* Libtool-basierte Builds dauern wesentlich länger als einfache Make-Builds für ein bestimmtes System, da libtool per Default alle Libraries mehrfach baut (shared, static, teilweise sogar optimiert und debug-Version schon während des Entwicklungszyklus), ~~so dass~~ Development-Turnaround-Cycles mit den Default-Einstellungen deutlich länger dauern können als bei anderen Systemen. Auch der Overhead der Macro- und Shell-Aufrufe kann auf einigen Nicht-Linux-Systemen signifikant ausfallen.		* Libtool-basierte Builds dauern wesentlich länger als einfache Make-Builds für ein bestimmtes System, da libtool per Default alle Libraries mehrfach baut (shared, static, teilweise sogar optimiert und debug-Version schon während des Entwicklungszyklus), sodass Development-Turnaround-Cycles mit den Default-Einstellungen deutlich länger dauern können als bei anderen Systemen. Auch der Overhead der Macro- und Shell-Aufrufe kann auf einigen Nicht-Linux-Systemen signifikant ausfallen.
	* In der Vergangenheit waren verschiedene Versionen von autoconf/automake/libtool/etc. nicht untereinander kompatibel; auf dem Entwicklungssystem mussten deshalb mehrere Versionen installiert und verwaltet werden, oder configure/Makefile-Input-Files erforderten ständige Anpassungen mit neuen Versionen.		* In der Vergangenheit waren verschiedene Versionen von autoconf/automake/libtool/etc. nicht untereinander kompatibel; auf dem Entwicklungssystem mussten deshalb mehrere Versionen installiert und verwaltet werden, oder configure/Makefile-Input-Files erforderten ständige Anpassungen mit neuen Versionen.
	* Das [[KDE]]-Team verzichtet seit KDE4 auf autoconf/automake/libtool/etc. und verwendet an seiner Stelle [[CMake]]. Auch andere Projekte begannen mit der Evaluierung alternativer Buildsysteme. [[Apache Ant\|Ant]] und [[Perforce Jam\|JAM]] sind weitere Ansätze. [[Integrierte Entwicklungsumgebung]]en (IDE) enthalten oft eigene Buildsysteme, die z. B. von CMake konfiguriert werden können.		* Das [[KDE]]-Team verzichtet seit KDE4 auf autoconf/automake/libtool/etc. und verwendet an seiner Stelle [[CMake]]. Auch andere Projekte begannen mit der Evaluierung alternativer Buildsysteme. [[Apache Ant\|Ant]] und [[Perforce Jam\|JAM]] sind weitere Ansätze. [[Integrierte Entwicklungsumgebung]]en (IDE) enthalten oft eigene Buildsysteme, die z. B. von CMake konfiguriert werden können.

Xenein: /* growthexperiments-addlink-summary-summary:1|1|0 */

2024-11-04T23:23:26Z

Linkvorschlag-Funktion: 1 Link hinzugefügt.

← Nächstältere Version		Version vom 5. November 2024, 01:23 Uhr
Zeile 9:		Zeile 9:
	''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.		''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.

	Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.		Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die [[Systemumgebung]] angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.

	Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].		Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].

Polluks: /* Einschränkungen des GNU Build System */

2021-08-28T20:52:20Z

Einschränkungen des GNU Build System

← Nächstältere Version		Version vom 28. August 2021, 22:52 Uhr
Zeile 64:		Zeile 64:
	Es werden möglicherweise nicht alle oder mehrere Kommandos benötigt, abhängig davon in welcher Weise das vorhandene Projekt das ''GNU Build System'' nutzt. Darüber hinaus ist es auch üblich, ein Skript zur Verfügung zu stellen, oftmals benannt als <code>autogen.sh</code>, das alle genannten Pre-Build-Tools ausführt. In einigen Fällen kann man auch		Es werden möglicherweise nicht alle oder mehrere Kommandos benötigt, abhängig davon in welcher Weise das vorhandene Projekt das ''GNU Build System'' nutzt. Darüber hinaus ist es auch üblich, ein Skript zur Verfügung zu stellen, oftmals benannt als <code>autogen.sh</code>, das alle genannten Pre-Build-Tools ausführt. In einigen Fällen kann man auch

	$ autoreconf		$ autoreconf --install

	benutzen, das automatisch die genannten Kommandos aufruft, falls sie benötigt werden.		benutzen, das automatisch die genannten Kommandos aufruft, falls sie benötigt werden.

Rolfg: Grammatik - Singular / Plural

2021-05-21T22:38:27Z

Grammatik - Singular / Plural

← Nächstältere Version		Version vom 22. Mai 2021, 00:38 Uhr
Zeile 31:		Zeile 31:

	=== GNU Autoheader ===		=== GNU Autoheader ===
	GNU Autoheader erzeugt eine Vorlage für eine Konfigurations-Header-Datei aus einer Autoconf-Konfigurationsdatei.<ref>http://www.seul.org/docs/autotut/#autoheader</ref> Die Verwendung von GNU Autoheader ist optional. GNU Autoconf bzw. Automake ist auch ohne GNU Autoheader verwendbar. Wenn Autoheader nicht verwendet wird, dann müssen die von dem Projekt benötigten Konfigurationsmakros als Parameter bei jedem Compiler-Aufruf übergeben werden. Also ~~kann~~ bei Nichtverwendung von autoheader, wenn das Projekt eine große Anzahl von Konfigurationsmakros benötigt, die Bildschirmausgaben von Compiler-Aufrufen unübersichtlich werden.		GNU Autoheader erzeugt eine Vorlage für eine Konfigurations-Header-Datei aus einer Autoconf-Konfigurationsdatei.<ref>http://www.seul.org/docs/autotut/#autoheader</ref> Die Verwendung von GNU Autoheader ist optional. GNU Autoconf bzw. Automake ist auch ohne GNU Autoheader verwendbar. Wenn Autoheader nicht verwendet wird, dann müssen die von dem Projekt benötigten Konfigurationsmakros als Parameter bei jedem Compiler-Aufruf übergeben werden. Also können bei Nichtverwendung von autoheader, wenn das Projekt eine große Anzahl von Konfigurationsmakros benötigt, die Bildschirmausgaben von Compiler-Aufrufen unübersichtlich werden.

	=== GNU Automake ===		=== GNU Automake ===

Rolfg: Der Verweis auf C++-Templates ist hier falsch. Da das Wort "Schablone" hier in seinem allgemeinverständlichen Sinn verwendet wird, ist kein Verweis besser als ein falscher.

2021-05-21T21:55:20Z

Der Verweis auf C++-Templates ist hier falsch. Da das Wort "Schablone" hier in seinem allgemeinverständlichen Sinn verwendet wird, ist kein Verweis besser als ein falscher.

← Nächstältere Version		Version vom 21. Mai 2021, 23:55 Uhr
Zeile 9:		Zeile 9:
	''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.		''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.

	Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten ~~[[Template (C++)\|~~Schablonen]].		Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.

	Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].		Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].

TaxonBot: Bot: Überarbeitung veralteter Syntax / HTML-Validierung

2021-04-10T11:38:32Z

Bot: Überarbeitung veralteter Syntax / HTML-Validierung

← Nächstältere Version		Version vom 10. April 2021, 13:38 Uhr
Zeile 34:		Zeile 34:

	=== GNU Automake ===		=== GNU Automake ===
	''Automake'' hilft bei der Erzeugung von portablen <code>Makefiles</code>, die der Reihe nach von <tt>[[make]]</tt> verarbeitet werden. Es erhält seine Eingaben als <code>Makefile.am</code> und wandelt es in eine <code>Makefile.in</code>-Datei um, die vom „configure“-Skript genutzt wird, um das letztendliche <code>Makefile</code> zu erzeugen.		''Automake'' hilft bei der Erzeugung von portablen <code>Makefiles</code>, die der Reihe nach von <span style="font-family:monospace;">[[make]]</span> verarbeitet werden. Es erhält seine Eingaben als <code>Makefile.am</code> und wandelt es in eine <code>Makefile.in</code>-Datei um, die vom „configure“-Skript genutzt wird, um das letztendliche <code>Makefile</code> zu erzeugen.

	=== GNU Libtool ===		=== GNU Libtool ===

Zero Thrust: /* Literatur */

2020-10-10T09:12:58Z

Literatur

← Nächstältere Version		Version vom 10. Oktober 2020, 11:12 Uhr
Zeile 82:		Zeile 82:
	== Literatur ==		== Literatur ==
	* Florian Stöhr: ''Die GNU Autotools : Leitfaden für die Softwaredistribution.'' C&L Computer & Literaturverlag, Böblingen 2007, ISBN 978-3-936546-48-4		* Florian Stöhr: ''Die GNU Autotools : Leitfaden für die Softwaredistribution.'' 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~~		* John Calcote: ''Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool.'' 2. Auflage, No Starch Press, Daly City, California 2019, ISBN 978-1-59327-972-1

	== Weblinks ==		== Weblinks ==

Polluks: /* Einschränkungen des GNU Build System */

2020-06-19T16:29:46Z

Einschränkungen des GNU Build System

← Nächstältere Version		Version vom 19. Juni 2020, 18:29 Uhr
Zeile 60:		Zeile 60:
	$ autoconf		$ autoconf
	$ autoheader		$ autoheader
	$ automake		$ automake --add-missing

	Es werden möglicherweise nicht alle oder mehrere Kommandos benötigt, abhängig davon in welcher Weise das vorhandene Projekt das ''GNU Build System'' nutzt. Darüber hinaus ist es auch üblich, ein Skript zur Verfügung zu stellen, oftmals benannt als <code>autogen.sh</code>, das alle genannten Pre-Build-Tools ausführt. In einigen Fällen kann man auch		Es werden möglicherweise nicht alle oder mehrere Kommandos benötigt, abhängig davon in welcher Weise das vorhandene Projekt das ''GNU Build System'' nutzt. Darüber hinaus ist es auch üblich, ein Skript zur Verfügung zu stellen, oftmals benannt als <code>autogen.sh</code>, das alle genannten Pre-Build-Tools ausführt. In einigen Fällen kann man auch

Trustable: stil

2020-04-06T18:22:56Z

stil

← Nächstältere Version		Version vom 6. April 2020, 20:22 Uhr
Zeile 42:		Zeile 42:
	Das GNU Build System stellt einem [[Programmierer]] eine Umgebung bereit, mit der er [[Cross-platform]]-Software programmieren kann (die zumindest auf verschiedenen [[unixoid]]en [[Betriebssystem]]en ausgeführt werden kann). Es vereinfacht außerdem den [[Erstellungsprozess\|Buildvorgang]], weil der Nutzer normalerweise nur wenige Kommandos ausführen muss, um das Programm aus dem [[Quellcode]] zu erzeugen und zu installieren.		Das GNU Build System stellt einem [[Programmierer]] eine Umgebung bereit, mit der er [[Cross-platform]]-Software programmieren kann (die zumindest auf verschiedenen [[unixoid]]en [[Betriebssystem]]en ausgeführt werden kann). Es vereinfacht außerdem den [[Erstellungsprozess\|Buildvorgang]], weil der Nutzer normalerweise nur wenige Kommandos ausführen muss, um das Programm aus dem [[Quellcode]] zu erzeugen und zu installieren.

	Die Werkzeuge, die vom ''GNU Build System'' benutzt werden, müssen dabei nur auf dem Computer des Entwicklers vorhanden sein. Die Nutzer selbst benötigen keine installierte Version von Autoconf, Automake oder Libtool, um die Software zu erstellen oder zu installieren, die mit deren Hilfe erzeugt wurde. Dies macht das ''GNU Build System'' ''unabhängig'', weil es zum Erstellen nur Standardtools benötigt, die auf allen [[unixoid]]en Systemen vorhanden sind. Dies wird durch die Benutzung von [[Unix-Shell\|~~Shell~~]]~~-Scripts~~ bewerkstelligt, die dabei helfen, das Programm für das Betriebssystem des jeweiligen Nutzers zu konfigurieren.		Die Werkzeuge, die vom ''GNU Build System'' benutzt werden, müssen dabei nur auf dem Computer des Entwicklers vorhanden sein. Die Nutzer selbst benötigen keine installierte Version von Autoconf, Automake oder Libtool, um die Software zu erstellen oder zu installieren, die mit deren Hilfe erzeugt wurde. Dies macht das ''GNU Build System'' ''unabhängig'', weil es zum Erstellen nur Standardtools benötigt, die auf allen [[unixoid]]en Systemen vorhanden sind. Dies wird durch die Benutzung von [[Unix-Shell\|Unix-Shellskripten]] bewerkstelligt, die dabei helfen, das Programm für das Betriebssystem des jeweiligen Nutzers zu konfigurieren.

	Die Werkzeuge, die im ''GNU Build System'' genutzt werden, können sowohl einzeln als auch gemeinsam genutzt werden; zum Beispiel kann ein Softwareprojekt Autoconf nutzen, ohne auch Automake zu nutzen. Allerdings können die Komponenten des ''GNU Build System'' auch miteinander interagieren.		Die Werkzeuge, die im ''GNU Build System'' genutzt werden, können sowohl einzeln als auch gemeinsam genutzt werden; zum Beispiel kann ein Softwareprojekt Autoconf nutzen, ohne auch Automake zu nutzen. Allerdings können die Komponenten des ''GNU Build System'' auch miteinander interagieren.

Trustable: deutsch

2020-04-06T18:15:13Z

deutsch

← Nächstältere Version		Version vom 6. April 2020, 20:15 Uhr
Zeile 17:		Zeile 17:
	Wird das generierte Konfigurationsscript ausgeführt, werden – soweit sie angegeben wurden – aus Vorlagen (die normalerweise die Endung „.in“ (z. B. <code>Makefile.in</code>) haben), die endgültigen Dateien generiert, in diesem Fall ein <code>Makefile</code>.		Wird das generierte Konfigurationsscript ausgeführt, werden – soweit sie angegeben wurden – aus Vorlagen (die normalerweise die Endung „.in“ (z. B. <code>Makefile.in</code>) haben), die endgültigen Dateien generiert, in diesem Fall ein <code>Makefile</code>.

	Autoconf wird dazu benutzt, kleinere Inkompatibilitäten auszubügeln, die in verschiedenen [[unixoid]]en Betriebssystemen gefunden wurden. Zum Beispiel haben einige unixoide Systeme Hilfsmittel, die als nicht funktionsfähig bekannt sind oder komplett fehlen. Autoconf erzeugt ein [[~~Shell-Skript~~]], welches dies erkennen und umgehen kann. Der Output des Autoconf-Werkzeuges ist das Konfigurationsskript.		Autoconf wird dazu benutzt, kleinere Inkompatibilitäten auszubügeln, die in verschiedenen [[unixoid]]en Betriebssystemen gefunden wurden. Zum Beispiel haben einige unixoide Systeme Hilfsmittel, die als nicht funktionsfähig bekannt sind oder komplett fehlen. Autoconf erzeugt ein [[Shellskript]], welches dies erkennen und umgehen kann. Der Output des Autoconf-Werkzeuges ist das Konfigurationsskript.

	Autoconf enthält einige Hilfsprogramme, die entwickelt wurden, um das Erzeugen von configure.ac zu vereinfachen, darunter das Autoheader-Tool, das dazu benutzt wird, [[C (Programmiersprache)\|C]]-[[Header-Datei]]en zu handhaben, Autoscan, das eine anfängliche Datei für Autoconf erzeugt und ifnames, welche die C-[[Präprozessor]][[identifier]] enthält, die im Programm benutzt werden.		Autoconf enthält einige Hilfsprogramme, die entwickelt wurden, um das Erzeugen von configure.ac zu vereinfachen, darunter das Autoheader-Tool, das dazu benutzt wird, [[C (Programmiersprache)\|C]]-[[Header-Datei]]en zu handhaben, Autoscan, das eine anfängliche Datei für Autoconf erzeugt und ifnames, welche die C-[[Präprozessor]][[identifier]] enthält, die im Programm benutzt werden.
Zeile 51:		Zeile 51:

	== Einschränkungen des ''GNU Build System'' ==		== Einschränkungen des ''GNU Build System'' ==
	Das ''GNU Build System'' nutzt [[Bourne-Shell\|Bourne-kompatible ~~Shellscripts~~]], um dem Nutzer bei der Konfiguration und dem Buildvorgang zu helfen. Allerdings können einige Betriebssysteme, wie die Produktreihe [[Microsoft Windows\|Windows]], Bourne-~~Shellscripte~~ nicht alleine ausführen. Dies macht das Erstellen von Software beim Windows-Betriebssystem ein bisschen schwieriger als das Erstellen auf [[unixoid]]en, die standardmäßig Unterstützung für Bourne-~~Shellscripte~~ implementiert haben.		Das ''GNU Build System'' nutzt [[Bourne-Shell\|Bourne-kompatible Shellskripte]], um dem Nutzer bei der Konfiguration und dem Buildvorgang zu helfen. Allerdings können einige Betriebssysteme, wie die Produktreihe [[Microsoft Windows\|Windows]], Bourne-Shellskripte nicht alleine ausführen. Dies macht das Erstellen von Software beim Windows-Betriebssystem ein bisschen schwieriger als das Erstellen auf [[unixoid]]en, die standardmäßig Unterstützung für Bourne-Shellskripte implementiert haben.

	Um Kompatibilität mit Konfigurationsscripts zu implementieren, kann man das [[Cygwin]]-System installieren. Cygwin liefert auch die [[GNU Compiler Collection]], [[GNU Make]] und andere Software, die ein nahezu komplettes unixoides System in Windows erstellt. In zunehmendem Maße wird mit [[MinGW]] dadurch auch Cross-Compiling ermöglicht, um Software für einen Windows-Host von einem GNU/Linux oder anderen unixoiden Buildsystemen zu erstellen.		Um Kompatibilität mit Konfigurationsscripts zu implementieren, kann man das [[Cygwin]]-System installieren. Cygwin liefert auch die [[GNU Compiler Collection]], [[GNU Make]] und andere Software, die ein nahezu komplettes unixoides System in Windows erstellt. In zunehmendem Maße wird mit [[MinGW]] dadurch auch Cross-Compiling ermöglicht, um Software für einen Windows-Host von einem GNU/Linux oder anderen unixoiden Buildsystemen zu erstellen.

← Nächstältere Version		Version vom 5. November 2024, 01:23 Uhr
Zeile 9:		Zeile 9:
	''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.		''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.

	Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.		Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die [[Systemumgebung]] angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.

	Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].		Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].

← Nächstältere Version		Version vom 21. Mai 2021, 23:55 Uhr
Zeile 9:		Zeile 9:
	''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.		''Autoconf'' ist eine [[Software]], die automatisch Shell-[[Skriptsprache\|Skripte]] generiert, die wiederum [[Makefile]]s für ein Softwarepaket erstellen, um das [[Compiler\|Übersetzen]] des [[Quellcode]]s für verschiedene [[Unix]]-Systeme (etwa [[Linux]]) zu ermöglichen. Die von Autoconf erstellten Skripte sind allein lauffähig und benötigen kein Autoconf.

	Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten ~~[[Template (C++)\|~~Schablonen]].		Autoconf verwendet GNU [[M4 (Programmiersprache)\|m4]], um aus einer vom Anwender erstellten Konfigurationsdatei ''configure.ac'' ein [[Plattformunabhängigkeit\|portierbares]] [[Shellskript]] namens ''configure'' zu erzeugen. Dieses ''configure''-Skript läuft ohne weitere Eingriffe des Benutzers und generiert an die Systemumgebung angepasste [[Header]]- und Makefiles aus vorgefertigten Schablonen.

	Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].		Autoconf wurde 1991 von David MacKenzie entwickelt, um seine Arbeit bei der [[Free Software Foundation]] zu vereinfachen. In den folgenden Jahren wuchs seine Bedeutung und es ist inzwischen das am häufigsten verwendete Konfigurationssystem für portierbare [[Open Source\|Open-Source-Software]].