Autokonf
 | |
| Originalförfattare | David Mackenzie |
|---|---|
| Utvecklare | GNU-projektet |
| Initial release | 1991 |
| Stabil frisättning | 2,71 / 28 januari 2021
|
| Förvar | |
| Skrivet i | Perl |
| Operativ system | Cross-plattform |
| Typ | Programmeringsverktyg |
| Licens | GNU GPL |
| Hemsida | |
GNU Autoconf är ett verktyg för att producera konfigureringsskript för att bygga, installera och paketera programvara på datorsystem där ett Bourne-skal är tillgängligt.
Autoconf är agnostisk om de programmeringsspråk som används, men det används ofta för projekt som använder C , C++ , Fortran , Fortran 77, Erlang eller Objective-C .
Ett konfigureringsskript konfigurerar ett programpaket för installation på ett visst målsystem. Efter att ha kört en serie tester på målsystemet genererar konfigureringsskriptet header-filer och en make-fil från mallar, vilket anpassar mjukvarupaketet för målsystemet. Tillsammans med Automake och Libtool bildar Autoconf GNU Build System , som omfattar flera andra verktyg, särskilt Autoheader.
Användningsöversikt
Utvecklaren specificerar det önskade beteendet för konfigureringsskriptet genom att skriva en lista med instruktioner på GNU m4 -språket i en fil som heter "configure.ac". Ett bibliotek med fördefinierade m4- makron är tillgängligt för att beskriva vanliga instruktioner för konfigureringsskript. Autoconf omvandlar instruktionerna i "configure.ac" till ett portabelt konfigureringsskript. Systemet som kommer att utföra byggnaden behöver inte ha autoconf installerat: autoconf behövs bara för att bygga konfigureringsskriptet, som vanligtvis levereras med programvaran.
Historia
Autoconf inleddes sommaren 1991 av David Mackenzie för att stödja hans arbete på Free Software Foundation . Under de efterföljande åren växte det till att inkludera förbättringar från en mängd olika författare och blev det mest använda byggkonfigurationssystemet för att skriva bärbar gratis eller öppen programvara .
Närma sig
Autoconf liknar Metaconfig-paketet som används av Perl . Det imake -system som tidigare användes av X Window System (upp till X11R6.9) är nära besläktat, men har en annan filosofi.
Autoconf-metoden för portabilitet är att testa för funktioner , inte för versioner . Till exempel stödde den inbyggda C-kompilatorn på SunOS 4 inte ISO C . Det är dock möjligt för användaren eller administratören att ha installerat en ISO C-kompatibel kompilator. Ett rent versionsbaserat tillvägagångssätt skulle inte upptäcka närvaron av ISO C-kompilatorn, men en funktionstestning skulle kunna upptäcka ISO C-kompilatorn som användaren hade installerat. Grunden för detta tillvägagångssätt är att få följande fördelar:
- konfigureringsskriptet kan få rimliga resultat på nyare eller okända system
- det tillåter administratörer att anpassa sina maskiner och låta konfigureringsskriptet dra fördel av anpassningarna
- det finns inget behov av att hålla reda på detaljer om versioner, patchnummer etc. för att ta reda på om en viss funktion stöds eller inte
Autoconf tillhandahåller omfattande dokumentation kring icke-portabiliteten av många POSIX-skalkonstruktioner till äldre skal och buggar däri. Den tillhandahåller också M4SH, en makrobaserad ersättning för skalsyntax.
Kritik
Det finns en del kritik som säger att Autoconf använder daterad teknologi, har många äldre begränsningar och komplicerar enkla scenarier i onödan för författaren till configure.ac -skript. Särskilt ofta citerade svaga punkter i Autoconf är:
- Allmän komplexitet av använd arkitektur, de flesta projekt använder flera upprepningar.
- Genererad 'configure' är skriven i Bourne-skalet och därför är genereringen av Makefile långsam.
- Vissa människor tror att "konfigurera"-skript som genereras av autoconf endast tillhandahåller manuellt styrt kommandoradsgränssnitt utan någon standardisering. Även om det är sant att vissa utvecklare inte respekterar vanliga konventioner, finns sådana konventioner och används ofta.
- M4 är ovanligt och okänt för många utvecklare. Utvecklare måste lära sig det för att utöka autoconf med icke-standardiserade kontroller.
- Svag bakåt- och framåtkompatibilitet kräver ett omslagsskript.
- Autoconf-genererade skript är vanligtvis stora och ganska komplexa. Även om de producerar omfattande loggning kan det fortfarande vara svårt att felsöka dem.
På grund av dessa begränsningar bytte flera projekt som använde GNU Build System till olika byggsystem, såsom CMake och SCons .
Se även
- CMake – Alternativt byggsystem
- Meson Ett annat byggsystem
- Konfigurera skript
- GNU byggsystem
- pkg-config – Upptäcker paketberoenden