Vielversprechende Alternativen? [geschlossen]

83

Ich benutze seit vielen Jahren make und makefiles und obwohl das Konzept solide ist, lässt die Implementierung zu wünschen übrig.

Hat jemand gute Alternativen gefunden, um das Problem nicht zu komplizieren?

build-automation  makefile 
— mike511
quelle
Wird die Antwort nicht stark davon abhängen, wo das Problem liegt? Für die Dinge, die ich versucht habe, makeist es zu simpel.
— Reinierpost
Ruby Rake, CoffeeScript Cake, Python Scons, Java Ant / Maven, C # MSBuild, plattformübergreifende CMake
— FilBot3
— Alex Efimov
makefile ist prägnant, aber eine Sprache für sich. Ich fand es schwierig zu debuggen. Für Python - Benutzer gibt es viele Pakete inklusive scons, luigi(angepasst shouldsee/luck) snakemake, waf. Es gibt viele Java-Alternativen, aber dieser Speicherplatz ist zu klein, um sie alle aufzuschreiben.
— sollte
Ich habe es noch nicht ausprobiert, aber github.com/casey/just klingt etwas vielversprechend, "erzeugt detaillierte Fehlermeldungen und vermeidet Eigenheiten von make, sodass das Debuggen eines Justfiles einfacher und weniger überraschend ist als das Debuggen eines Makefiles"
— Dr. Jan-Philip Gehrcke

Antworten:

30

Schauen Sie sich SCons an . Zum Beispiel nutzen Doom 3 und Blender es.

— WaldWolf
quelle
+1 für Scons - konzeptionell ähnlich genug, um es leicht zu machen, den Kopf herumzukriegen, aber einige der schlimmeren Probleme mit make zu beheben (z. B. den Umgang mit Leerzeichen in Namen).
— Tom
5
SCons ist nur Python 2, und nachdem Sie Tage damit verbracht haben, SCons zum Kompilieren einer Python 3-Version eines in Python und C ++ geschriebenen Projekts zu verwenden, würde ich den Leuten raten, sich fernzuhalten. Verwenden Sie einfach CMake, es wird zu diesem Zeitpunkt zum Standard für C ++. Oder wenn Sie ein Python-basiertes Build-System verwenden möchten, verwenden Sie Meson . Es läuft schnell und wird aktiv weiterentwickelt, was für SCons nicht gesagt werden kann.
— Ostrokach
SCons unterstützt Python 3 seit September 2017 (5 Monate nachdem der obige Kommentar verfasst wurde) und ist Python 3 erst seit Version 4.0 (Juli 2020).
— Michael Platings
27

Ich habe viele Freunde, die CMake für die plattformübergreifende Entwicklung schwören:

http://www.cmake.org/

Es ist das Build-System, das unter anderem für VTK verwendet wird, eine C ++ - Bibliothek mit plattformübergreifenden Python-, Tcl- und Java-Bindungen. Ich denke, es ist wahrscheinlich die am wenigsten komplizierte Sache, die Sie mit so vielen Funktionen finden werden.

Sie können immer die Standard- Autotools ausprobieren . Automake-Dateien lassen sich recht einfach zusammenstellen, wenn Sie nur unter Unix arbeiten und sich an C / C ++ halten. Die Integration ist komplizierter und Autotools sind alles andere als das einfachste System aller Zeiten.

— Todd Gamblin
quelle
9
Beachten Sie, dass CMake immer noch nur Makefiles generiert. Wenn das Problem bei der Implementierung von GNU Make darin besteht, dass es nicht das tun kann, was Sie wollen, hilft Ihnen CMake wahrscheinlich nicht weiter. Oder Autotools.
— Tom
14
CMake generiert nicht nur Makefiles. CMake kann Tonnen verschiedener Arten von Build-Dateien generieren, die auf Tonnen verschiedener Compiler und Plattformen abzielen. Ich persönlich hasse CMake, weil die Konfigurationssyntax absolut widerlich ist.
— Taywee
19

doit ist ein Python-Tool. Es basiert auf den Konzepten von Build-Tools, ist aber allgemeiner.

  • Sie können festlegen, wie eine Aufgabe / Regel auf dem neuesten Stand ist (nicht nur Zeitstempel überprüfen, Zieldateien sind nicht erforderlich).
  • Abhängigkeiten können von anderen Aufgaben dynamisch berechnet werden
  • Aufgabenaktionen können Python-Funktionen oder Shell-Befehle sein
— schettino72
quelle
1
danke diese Antwort, doit sieht aus wie ein erstaunliches Werkzeug
— Bedros
16

Einige der GNOME-Projekte wurden auf waf migriert .

Es basiert auf Python, wie Scons, ist aber auch eigenständig. Anstatt dass andere Entwickler Ihr bevorzugtes Build-Tool installieren müssen, kopieren Sie einfach das eigenständige Build-Skript in Ihr Projekt.

— Eric Talevich
quelle
13

Ich empfehle die Verwendung von Rake . Es ist das einfachste Werkzeug, das ich gefunden habe.

Andere gute Werkzeuge, die ich verwendet habe, wenn Ruby nicht dein Ding ist, sind:

  • AAP (Python)
  • SCons (Python)
  • Ant (Java, Konfiguration in XML, ziemlich komplex)
— Clinton Dreisbach
quelle
7

ninjaBeachten Sie das Build-Tool (v1.8.2 Sept 2017), das von tupund beeinflusst wird redo.

Der Build-Datei-Generator cmake(z. B. für Unix-Makefiles, Visual Studio, XCode, Eclipse CDT ninjausw. ) kann seit Version 2.8.8 (April 2012) auch Build-Dateien generieren und ninjaist jetzt sogar das Standard-Build-Tool von cmake.

Es soll das makeTool übertreffen (bessere Abhängigkeitsverfolgung und ist auch parallelisiert).

cmakeist ein bereits etabliertes Tool. Sie können das Build-Tool später jederzeit auswählen, ohne Ihre Konfigurationsdateien zu ändern. Wenn also in Zukunft ein besserer Build entwickelt wird, der von cmakeIhnen unterstützt wird , können Sie bequem darauf umsteigen.

Beachten Sie, dass für c / c ++ die Verbesserung der Kompilierungszeit manchmal begrenzt ist, da Header über den Präprozessor enthalten sind (insbesondere bei Verwendung von Nur-Header-Bibliotheken, z. B. boost & eigen ), die hoffentlich durch den Vorschlag von Modulen (in einer technischen Überprüfung) ersetzt werden von c ++ 11 oder eventuell in c ++ 1y). In dieser Präsentation finden Sie Details zu diesem Problem.

— Hotschke
quelle
3
Hängt insbesondere tupdavon ab, fuseob die Sicherungskernerweiterung ausgeführt wird, was meiner Meinung nach darauf hindeutet, dass die Betreuer verrückt sind. redowurde seit zwei Jahren nicht mehr aktualisiert. Ich würde empfehlen ninja.
— mxcl
5

Ich habe ein Tool namens Sake geschrieben , mit dem versucht wurde, das Schreiben von Makefile-ähnlichen Dingen sehr einfach zu lesen und zu schreiben.

— Tonyfischetti
quelle
Interessant; Aber können Sie uns ein paar Informationen darüber geben, warum Sake Ihrer Meinung nach leichter zu lesen und zu schreiben ist? Wir sollten das Projekt nicht installieren müssen, um zu sehen, dass es die Frage beantwortet.
— Dour High Arch
Sicher! Es klang für mich wie ein Teil des Grundes, warum der Autor der ursprünglichen Frage besorgt über die Implementierung von Make war, "das Problem zu komplizieren", weil die Syntax von makefiles unklar war. Sake verwendet Dateien, die in YAML geschrieben sind und nach meinen Angaben viel einfacher zu lesen und zu schreiben sind.
— Tonyfischetti
Die Tatsache, dass YAML-Syntax verwendet wird, sollte Teil der Antwort sein, möglicherweise mit einigen Erläuterungen zum Kontrast von YAML und makeSyntax.
— Aaron Novstrup
Ich habe Sake gerade für ein Build-Skript verwendet und es ist großartig. Danke, dass du es geschrieben hast!
— Nooblar
Sake ist erstaunlich einfach.
— Dan
4

Es hängt irgendwie davon ab, was Sie versuchen zu tun. Wenn alle Sie Make-Stil Ziel Abhängigkeiten und Befehlsaufruf ist, dann ist Make tatsächlich eines der besseren Tools für die Aufgabe. :-) Rake ist sehr schön, kann aber in einigen einfachen Fällen ungeschickt sein. Ant ist natürlich eine Stadt der Ausführlichkeit, aber es bietet eine bessere Unterstützung für den Aufbau von Java-ähnlichen Sprachen (einschließlich Scala und Groovy). Außerdem ist Ant überall verfügbar . Das ist der Hauptgrund, warum ich es benutze. Da es unter Windows konsistent funktioniert, ist es sogar noch plattformübergreifender als Make.

Wenn Sie das Abhängigkeitsmanagement für Java-ähnliche Bibliotheken wünschen, ist Maven die kanonische Wahl, aber ich persönlich mag Buildr viel besser. Es ist schneller und viel einfacher anzupassen (es basiert auf Rake). Leider ist es noch nicht so allgegenwärtig wie Maven.

— Daniel Spiewak
quelle
2

Ich bevorzuge es immer noch zu machen, nachdem ich einige der Alternativen in Betracht gezogen habe. Wenn Sie Abhängigkeiten entweder über den Compiler oder über Fastdep automatisch generieren, bleibt nicht viel zu tun. Insbesondere möchte ich nicht, dass mein Build-Skript an die Implementierungssprache gebunden ist, und ich schreibe nicht gerne in XML, wenn besser lesbare Alternativen verfügbar sind. Ein Werkzeug, das eine Allzwecksprache verfügbar macht, hat zwar Vorteile, eine andere interpretierte Sprache jedoch nicht (afaik). Was ist falsch an Make? könnte Ihren Standpunkt über die Abkehr von make ansprechen.

/ Allan

— Allan Wind
quelle
Ich bevorzuge auch Make; Es ist ein Moorstandard, der überall verfügbar ist, und es besteht eine vernünftige Chance, dass jeder, der neu im Projekt ist, ihn zuvor verwendet hat (oder zumindest eine bessere Chance als alles andere). Aber. Ich habe eine große Codebasis (mehrere tausend C ++ - Quelldateien), die für Visual C ++ geschrieben wurde und die ich unter GCC unter Linux erstellen möchte. Make schien die offensichtliche Wahl für ein Build-Tool zu sein, und wir haben einen schnellen und schmutzigen Konverter geschrieben, der vcxproj-Dateien analysiert und Makefiles erstellt. Es war alles großartig, bis wir es an einem Projekt mit einem Leerzeichen im Namen versuchten. Was sollen wir tun?
— Tom
Für die Aufzeichnung habe ich mit SCons gelandet. Da unser Konverter sowieso in Python geschrieben wurde, war es ziemlich einfach, ihn stattdessen in ein SConscript zu konvertieren.
— Tom
@ Tom Wo können wir eine Kopie des vcxproj-Datei-Parsers bekommen? Auch ich arbeite an einem kleinen Projekt unter Windows und möchte auf Ubuntu portieren.
— Dan
@ Maverick - ich entschuldige mich, es war proprietär und ich arbeite dort nicht mehr. Ich fürchte, die Neuerstellung ist für komplexe Build-Systeme nicht trivial. Während die VS-Arbeitsbereichsdatei "nur XML" ist und es nicht allzu schrecklich ist, herauszufinden, welche Quelldateien erstellt und welche Optionen angewendet werden sollen, müssen Sie Build-Konfigurationen (Debug, Release) berücksichtigen und auch, dass die Lösung und einzelne Projekte dies können Importieren Sie auch beliebige andere msbuild-Dateien. Eine andere Option, die wir in Betracht gezogen haben, war die Verwendung von msbuild als Ziel für GCC - und Sie finden dies jetzt möglicherweise einfacher, da msbuild seitdem stark ausgereift ist.
— Tom
1

FlowTracer von RTDA ist eine weitere gute Wahl, die ich kommerziell in einer großen Umgebung (Zehntausende von Jobs) gesehen habe: http://www.rtda.com/flowtracer-design-flow-infrastructure-software

Es verfügt über eine grafische Benutzeroberfläche, die das Abhängigkeitsdiagramm mit farbcodierten Feldern für Jobs und Ovalen für Dateien anzeigt. Wenn die Anzahl der Jobs und Dateien hoch wird, ist ein GUI-basiertes Tool wie FlowTracer ziemlich wichtig.

Die anfänglichen Einrichtungskosten sind höher als bei Make. Es gibt eine Lernkurve zum Einrichten Ihres ersten Flusses damit. Danach wird es schneller.

— bu11d0zer
quelle
0

Ich bin mir nicht sicher, ob Sie hier die richtige Frage stellen.

Bist du nach einer vereinfachten Marke? In diesem Fall benötigen Sie jemanden, der mit make sehr vertraut ist, um eine Reihe von (M | m) Akefiles zu erstellen, die Ihr Problem vereinfachen.

Oder möchten Sie sich die zugrunde liegende Technologie ansehen? Wollen wir eine Architektur vom Typ Design-by-Contract erzwingen, die in das Code-Design integriert und in dieses erzwungen wird? Oder möglicherweise die Sprache selbst, zB Ada und ihr Konzept von Spezifikationen (Schnittstellen) und Körpern (Implementierungen)?

Welche Richtung Sie verfolgen, wird definitiv die möglichen Ergebnisse einer solchen Frage beeinflussen?

Grundsätzlich gibt es neue Möglichkeiten, Systeme nur aus den Komponenten zu erstellen, die sich wirklich geändert haben, gegenüber der Einführung neuer Technologien, bei denen solche Mechanismen vom Entwurf her eingebaut sind.

Entschuldigung, es ist keine direkte Antwort. Ich wollte nur versuchen, Sie dazu zu bringen, zu bewerten, welchen Weg Sie einschlagen wollten.

Prost,

rauben

— Rob Wells
quelle
Eine einfache Antwort auf eine komplexe Frage ist nicht möglich. Eine stärkere Fokussierung auf die Frage würde helfen.
— Rob Wells
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.