Gibt es eine Möglichkeit, Software-Builds / Compilation schneller zu machen? Wir haben einen Build-Baum c, c ++ mit Makefile, das für neue Builds fast 2 Stunden dauert. Ich bin auf einige kommerzielle Lösungen wie ElectricAccelerator, Sparkbuild gestoßen, gibt es irgendwelche Opensource-Entsprechungen?
Vielleicht möchten Sie sich distcc , ccache ansehen und natürlich -j make option.
Eine Suche bei Google könnte helfen, eine Liste von Open-Source-Software zu erhalten.
Wr.t Ihr Code können Sie Folgendes tun, um Build-Zeiten zu reduzieren:
In unserer Firma hatten wir eine Menge Produkte, die eine längere Bauzeit haben wie 3-6 Stunden.
Es gibt 2 Techniken, die wir verwendet haben.
-j -Option von make
Eine Möglichkeit besteht darin, den Build einfach auf schnellerer Hardware auszuführen. Ich stelle fest, dass dies nicht immer eine Option ist, aber es ist immer noch etwas zu beachten.
Wie @Martin erwähnt, beinhalten einige spezielle zu aktualisierende Untersysteme die Verwendung einer so schnellen Festplatte wie eine SSD, das Hinzufügen von mehr RAM, eine schnellere CPU (und mehr Kerne, wenn Ihr Compiler sie verwenden kann) und Sicherstellen, dass die zu erstellenden Dateien alle lokal auf dem Erstellungscomputer (nicht im Netzwerk) sind.
Sie sollten dem Build-Prozess auch so viel wie möglich von diesem Ressourcen-Pool geben, also entfernen Sie alle nicht-Build-bezogenen Prozesse und Anwendungen von der Build-Maschine. Dies wird jegliche Ressourcenkonkurrenz reduzieren.
Wir verwenden eine Kombination aus distmake , ccache und a makefile-generator , die ein parallelisierbares Makefile erstellt. C/C++ builds können extrem gut parallelisieren; oft können alle .o -Dateien parallel kompiliert werden.
Distmake ist eine verteilte Implementierung von make, basierend auf gnu make und veröffentlicht unter GPL. Ich behalte es. Sie können damit mehrere Hosts parallelisieren. Dies erfordert, dass alle Hosts die gleiche Ansicht des Dateisystems haben, z. NFS, so dass derselbe Befehl auf jedem Build-Host ausgeführt werden kann.
Das Deaktivieren von Optimierungen führt tendenziell zu schnelleren Builds, wenn Sie diese Option haben.
Wenn Sie bereits eine parallele Build-Architektur verwenden und diese immer noch langsam ist, müssen Sie sie vielleicht nur untersuchen. Beobachten Sie den Fortschritt mit einer Stoppuhr und sehen Sie, wo es Engpässe gibt. Suchen Sie nach "langen Stangen", die Sie vielleicht nicht erwartet haben. Viel Glück.
Sie haben Ihre Konfigurationssoftware nicht angegeben, aber wir haben ein Problem mit dem Clearcase entdeckt. Da Dateien auf Dateibasis ausgewertet werden, kann das Öffnen einer Datei ein Engpass sein. Denken Sie nur darüber nach, weiter zu lesen, wenn Sie mit einem Clearcase "festhängen".
Wir haben also festgestellt, dass Sie Ihre Build-Zeit auf 1/30 der Zeit (für uns) reduzieren können, indem Sie Ihre Include-Wächter für Header-Dateien ändern.
Grundsätzlich haben Sie in Ihren Header-Dateien oben einen Wächter wie:
%Vor%Dann weg von woanders, du schließt foo.h ein. Richtig, naja, wir fanden das aufgrund einer schrecklichen Kopplung von Dateitypen und so, dass einige allgemeine Header für jede von uns kompilierte .c-Datei hunderte Male eingeschlossen wurden. Mit dem Fehler im Design von Clearcase heißt das, dass man jede dieser Dateien hunderte Male öffnet, nur um den Inhalt zu ignorieren und die Datei wieder zu schließen.
Also ... statt nur ein #include für foo, benutze den Wächter, um foo bedingt einzuschließen. Normalerweise ist das eine schlechte Übung und ein schrecklicher Alptraum (wenn jemand anfängt, die Wachen zu wechseln).
Also ... in Ihrer .c-Datei würden Sie etwas tun wie:
%Vor%Wie ich schon sagte ... schlechte Praxis, aber wenn Sie Clearcase verwenden und es mit 3-4 Bauzeiten (wie wir es hatten) beißen, ... könnte es sich lohnen, darüber nachzudenken (oder einfach nur eine Kopie Ihres ganzen Baumes zu machen) außerhalb des Klarglases). Oder Graben Clearcase. Oder machen Sie einen besseren Job mit Typ-Abhängigkeiten.
Wir waren in der Lage, einige der am häufigsten verwendeten Includes zu "reparieren" und eine ziemlich dramatische Verbesserung der Build-Zeiten zu erreichen.