Kann Autotools Multi-Plattform-Makefiles erstellen

StackOverflow https://stackoverflow.com/questions/324134

Frage

Ich habe ein Plugin Projekt, das ich seit ein paar Jahren habe entwickelt, wo das Plugin mit zahlreichen Kombinationen von Arbeiten [primäre Anwendungsversion, 3rd-Party-Bibliothek Version, 32-Bit oder 64-Bit]. Gibt es eine (saubere) Art und Weise Autotools zu verwenden, um eine einzelne Make-Datei zu erstellen, die alle Versionen des Plugins baut.

Soweit ich von Skimming durch die Autotool Dokumentation sagen kann, ist die nächste Annäherung an, was Ich mag würde, ist N unabhängige Kopien des Projektes zu haben, jede mit ihrer eigenen Make-Datei. Dies scheint ein wenig suboptimal für die Prüfung und Entwicklung (a) ich brauchen würde, um kontinuierlich Code-Änderungen über die verschiedenen Kopien und (b) gibt es eine Menge von verschwendeten Speicherplatz in Duplizieren dem Projekt so viele Male zu propagieren. Gibt es einen besseren Weg?

EDIT:

Ich habe meine eigene Lösung für eine Weile rollen, wo ich Lust Make-Datei und einigen Perl-Skripte auf der Jagd nach verschiedenen 3rd-Party-Bibliothek Versionen usw. Als solche habe, ich bin offen für andere Nicht-Autotools-Lösungen. Für andere Build-Tools, würde ich will, dass sie sehr einfach sein für den Endverbraucher zu installieren. Die Werkzeuge müssen auch klug genug, um verschiedene 3rd-Party-Bibliotheken zu jagen und Header ohne eine riesige Menge Ärger. Ich suche vor allem für eine Linux-Lösung, sondern eine, die auch für Windows funktioniert und / oder der Mac wäre ein Bonus.

War es hilfreich?

Lösung

Soweit ich weiß, Sie können das nicht tun. Sie sind jedoch mit Autotool stecken? Sind weder CMake noch SCons eine Option?

Andere Tipps

Wenn Ihre Frage ist:

  

Kann ich die Autotools auf einiger Maschine A eine einzige universelle Make-Datei zu erstellen, die auf allen anderen Maschinen funktionieren werden?

dann ist die Antwort „Nein“. Die Autotools machen nicht einmal einen Vorwand zu versuchen, das zu tun. Sie sind so konzipiert portablen Code enthalten, die bestimmen, wie ein tragfähiges Make-Datei auf dem Zielcomputer erstellen.

Wenn Ihre Frage ist:

  

Kann ich die Autotools verwenden Software zu konfigurieren, die auf verschiedenen Rechnern ausgeführt werden muss, mit verschiedenen Versionen der primären Software, die mein Plugin mit arbeitet, sowie verschiedene 3rd-Party-Bibliotheken, keine 32-Bit vs 64-Bit-Ausgaben zu erwähnen?

dann ist die Antwort „Ja“. Die Autotools sind so konzipiert, der Lage sein, das zu tun. Ferner arbeiten sie auf Unix, Linux, MacOS X, BSD.

Ich habe ein Programm, SQLCMD (die vorge datiert das Microsoft-Programm mit dem gleichen Namen von einem Jahrzehnt und mehr), die mit den IBM Informix-Datenbanken arbeitet. Er erkennt die Version der Client-Software (so genannten IBM Informix ESQL / C, einen Teil des IBM Informix ClientSDK oder CSDK) installiert ist, und ob es sich um 32-Bit oder 64-Bit. Er erkennt auch, welche Version der Software installiert ist, und paßt seine Funktionalität zu dem, was in dem Träger Produkt zur Verfügung steht. Es unterstützt die Versionen, die über einen Zeitraum von etwa 17 Jahren veröffentlicht wurden. Es wird automatisch konfiguriert - ich einige autoconf Makros für die Informix-Funktionalität zu schreiben hatte, und ein paar andere Spielereien (hohe Auflösung Timing, das Vorhandensein von / dev / stdin usw.). Aber es ist machbar.

Auf der anderen Seite, ich weiß nicht versuchen, eine einzelne Make-Datei freigeben, die alle Kundenmaschinen und Umgebungen passen; es gibt einfach zu viele Möglichkeiten, dass sinnvoll. Aber Autotools kümmert sich um die Details für mich (und meine Benutzer). Alles, was sie tun, ist: 

./configure

Das ist einfacher, als herauszufinden, wie die Make-Datei zu bearbeiten. (Oh, für die ersten 10 Jahre wurde das Programm von Hand konfiguriert Es war schwer für die Menschen zu tun, obwohl ich ziemlich gut Ausfälle hatte aufgebaut Deshalb war ich für die automatische Konfiguration bewegt.. Es macht es viel einfacher für Menschen zu installieren.)

Herr Fooz kommentiert:

  

Ich möchte etwas dazwischen. Die Kunden werden mehrere Versionen und bitnesses der gleichen Basisanwendung auf derselben Maschine in meinem Fall verwenden. Ich bin nicht besorgt über Querübersetzbarkeit wie Erstellen von Windows-Binärdateien auf Linux.

Sie benötigen einen separaten Build Ihres Plugins für die 32-Bit- und 64-Bit-Versionen? (Ich würde davon ausgehen, ja -. Aber man konnte mich überraschen) Sie müssen also einen Mechanismus schaffen, für den Benutzer zu sagen 

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

(., Wo tppkg ein Code für Drittanbieter-Paket ist, und die Lage ist vorgebbar durch den Benutzer) jedoch im Auge behalten, die Benutzerfreundlichkeit: Je weniger solche Optionen der Benutzer hat zur Verfügung zu stellen, desto besser; gegen das, nicht hart Code Dinge, die optional, wie installieren Stellen sein sollte. Mit allen Mitteln in Standardpositionen finden - das ist gut. Und die Standard Sie auf die Stippen der Sachen finden. Vielleicht sowohl 32-Bit-, wenn Sie finden, und 64-Bit-Versionen, dann sollten Sie beide bauen - die sorgfältige Konstruktion erfordern würde, though. Sie können immer Echo „Prüfen auf TP-Package ...“ und zeigen, was Sie gefunden und wo Sie es gefunden. Dann kann der Installateur die Optionen ändern. Stellen Sie sicher, dass Sie dokumentieren in ‚./configure --help‘, was die Optionen sind; dies ist Standard Autotools Praxis.

Sie aber nicht interaktiv alles tun; configure laufen soll, berichten, was es tut. Das Perl Configure Skript (beachten Sie die Großbuchstaben - es ist ein völlig getrenntes automatisches Konfigurationssystem) ist eine der wenige intensiv interaktiven Konfigurationssysteme links (und das ist wahrscheinlich vor allem wegen seiner Erbe, wenn neu starten, wäre es höchstwahrscheinlich nicht sein -interactive). Solche Systeme sind eherein Ärgernis zu konfigurieren ist als die nicht-interaktive diejenigen.

Cross-Compilation ist hart. Ich habe es nie tun musste, Gott sei Dank.

Herr Fooz auch kommentiert:

  

Vielen Dank für die zusätzlichen Kommentare. Ich bin auf der Suche nach so etwas wie: 

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2
  

Dabei gilt es würde schaffen sowohl die 32-Bit- und 64-Bit-Targets in einer Make-Datei für die aktuelle Plattform.

Nun, ich bin sicher, dass es getan werden könnte; Ich bin mir nicht so sicher, dass es sich lohnt, im Vergleich zu zwei getrennten Ausführenden läuft mit einem kompletten Umbau dazwischen. Sie würden wahrscheinlich verwenden möchten: 

./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2

Dies zeigt die zwei separate Verzeichnisse. Sie müssten entscheiden, wie Sie den Build tun werden, aber vermutlich würden Sie zwei Unterverzeichnisse haben, wie ‚obj-32‘ und ‚obj-64‘ für die einzelnen Sätze von Objektdateien zu speichern.

: Sie würden auch Ihre Make-Datei nach dem Vorbild der arrangieren 
FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...

TPPKG32DIR = @TPPKG32DIR@
TPPKG64DIR = @TPPKG64DIR@

OBJ32DIR = obj-32
OBJ64DIR = obj-64

BUILD_32 = @BUILD_32@
BUILD_64 = @BUILD_64@

TPPKGDIR =
OBJDIR   =
FLAGS    =

all:    ${BUILD_32} ${BUILD_64}

build_32:
    ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build

build_64:
    ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build

build:  ${OBJDIR}/plugin.so

Dies setzt voraus, dass das Plugin ein gemeinsames Objekt sein würde. Die Idee dabei ist, dass das Autotool der 32-Bit- oder 64-Bit-Installationen für das Third Party-Paket erkennen würde, und dann Ersetzungen machen. Das BUILD_32 Makro würde eingestellt werden, um build_32, wenn das 32-Bit-Paket wurde ansonsten leer erforderlich und links; die BUILD_64 Makro ähnlich gehandhabt werden würde.

Wenn der Benutzer läuft ‚make all‘, wird es das Ziel build_32 erste und das build_64 Ziel nächsten bauen. Um das build_32 Ziel zu bauen, wird es erneut ausführen make und konfigurieren Sie die Flags für ein 32-Bit-Build. In ähnlicher Weise das build_64 Ziel zu bauen, wird es erneut ausführen make und konfigurieren Sie die Flags für ein 64-Bit-Build. Es ist wichtig, dass alle Flags betroffen von 32-Bit-vs 64-Bit-Builds auf dem rekursiven Aufruf von make gesetzt sind, und dass die Regeln für den Bau von Objekten und Bibliotheken werden sorgfältig geschrieben - zum Beispiel der Regel Quelle für das Kompilieren muss zum Objekt vorsichtig sein, die Objektdatei in dem richtigen Objektverzeichnis zu platzieren - mit GCC, zum Beispiel, würden Sie (in einer .c.o Regel) angeben: 

${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c

Das Makro CFLAGS würde die $ {} FLAGS Wert, der mit den Bits behandelt (zum Beispiel FLAGS_32 = -m32 und FLAGS_64 = -m64, and so when building the 32-bit version,FLAGS = -m32would be included in theCFLAGS` Makro.

Die verbleibenden Fragen in den Autotool arbeiten, wie die 32-Bit und 64-Bit-Flags zu bestimmen. Wenn die schlimmsten kommt, werden Sie Makros für diese selbst schreiben müssen. Aber ich würde erwarten, dass (ohne es erforscht haben), dass Sie tun können, es Standard-Einrichtungen von der Autotools Suite.

Wenn Sie sich selbst eine sorgfältig erstellen (auch rücksichtslos) symmetrische Make-Datei, es wird nicht zuverlässig arbeiten.

Wir haben versucht, und es funktioniert nicht! So nutzen wir jetzt SCons .

Einige Artikel zu diesem Thema: 1 und 2

Edit: Einige kleines Beispiel, warum ich SCons lieben: 

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

Mit dieser Codezeile Sie GLib zum Kompilieren Umgebung hinzufügen ( env ). Und vergessen Sie nicht die Benutzerhandbuch die einfach toll zu lernen SCons (Sie wirklich brauchen nicht Python zu wissen!). Für die Endanwender könnten Sie SCons mit PyInstaller oder so etwas versuchen.

Und im Vergleich zu make, die Sie verwenden Python, so eine komplette Programmiersprache! In diesem Sinne können Sie tun einfach alles (mehr oder weniger).

Haben Sie schon einmal ein einzelnes Projekt mit mehreren Build-Verzeichnisse zu verwenden, in Betracht gezogen? wenn Ihr auto Projekt wird in geeigneter Weise umgesetzt (d.h .: NICHT wie gcc)

ist folgendes möglich: 

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

Sie sind in der Lage verschiedene Konfigurationsparameter passieren wie Einfügeverzeichnisse und Compiler (Cross-Compiler d.).

Sie können dann auch diese laufen in einem einzigen make Anruf, indem Sie 

make -C build1 -C build2 -C build3
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top