CMake, C++, Jenkins/Continuous integration
Habe ich ein cmake-Beispielprojekt, das würde ich gerne bauen auf dem Jenkins läuft auf Ubuntu 15.10. Ich habe installiert:
https://wiki.jenkins-ci.org/display/JENKINS/CMake+Plugin
Erstellt und zwei build-Schritte:
- Cmake zu generieren makefiles
- Laufen alle aus dem build-dir
Ich gut funktioniert:
[build] $ cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug /var/lib/jenkins/workspace/cmake-test/cmake-gtest/src
-- Configuring done
-- Generating done
-- Build files have been written to: /var/lib/jenkins/workspace/cmake-test/cmake-gtest/build
[build] $ /usr/bin/make
[ 4%] Built target libfoo
[ 9%] Built target libbar
[ 14%] Built target myApp
[ 52%] Built target gmock
[ 90%] Built target gtest
[100%] Built target testfoo
[cmake-test] $ /bin/sh -xe /tmp/hudson1792271459427590561.sh
+ cd cmake-gtest/build
+ make all
[ 4%] Built target libfoo
[ 9%] Built target libbar
[ 14%] Built target myApp
[ 52%] Built target gmock
[ 90%] Built target gtest
[100%] Built target testfoo
Finished: SUCCESSAber ist dies die empfohlene Methode für die Verwendung von cmake in einer CI/Jenkins-setup?
Derzeit mein cmake/Jenkins-build wird auf jedem drücken; 1) erzeugen der makefiles, 2) erstellen Sie das Projekt.
Ich bin ein bisschen besorgt, dass der erste Schritt 1) das generieren von makefiles würde Essen, bis die build-Zeit und es scheint nicht wirklich das optimale zu tun Sie diesen Schritt auf jedem push. Vor allem, da würde ich nicht erwarten, zu ändern CMakeLists.txt Dateien, die oft, aber wenn Sie sich ändern, neue Dateien erzeugt, sollte der natürlich benutzt werden.
Ist der obige Ansatz Verfahren, dass ich nur noch gewöhnen, oder habe ich etwas verpasst?
- Die "Erzeugung von makefile" nehmen Sie ausreichend Zeit, sich sorgen zu machen? Während es nicht sein kann, ändern sich sehr oft, dass ein separater Schritt oder vermasselt die bauen, wenn es änderungen gibt ist wirklich keine schöne Lösung ...
- Ja das ist auch meine Sorge, Vorsicht ist besser als Nachsicht, würde eine Lösung sein, um sicherzustellen, Sie brechen meine Anwendung in kleinere Teile schneller, wenn es wächst. Regading die beiden bauen obigen Schritten 1) cmake generieren, 2) führen Sie alle ist es irgendwie etwas zu tun, dass Sie als Teil der code-Generierung? Oder sind Sie völlig unabhängig und sollten so behandelt werden?
- Ich bin mir nicht ganz sicher, was Ihr bittet. Meine Haltung im Allgemeinen, ist auf die einfachste Lösung, die ausreichend ist, um lösen das aktuelle problem", und nicht erschweren etwas, bis Sie wirklich einen guten Grund haben. Ich betreibe drei verschiedene jobs auf meinem Jenkins-system (zu Hause): "Bauen + führen Sie alle tests mit clang++", "Bauen + führen Sie alle tests mit g++" - diesen check alle 15 Minuten auf neue commits im git repo, und die Dritte ist, laden Sie die version von LLVM und mein code und bauen Sie alle zusammen, basierend auf einem build-Skript in das Projekt - einmal in der Nacht.
- Aus den obigen screenshot habe ich zwei build-Schritte: 1: erzeugen makefiles, 1: run machen. Ich Frage mich nur, wenn es getan werden könnte, in einem Schritt, und wenn cmake hat einige post-Schritt-Befehl für das eigentliche bauen, nachdem die Dateien generiert worden sind.
- Scheint sinnvoll, der Sie benötigen, zu tun beide trotzdem. Der einzige Vorteil, der sich aus zwei teilen ist, wenn es dauert lange genug, dass der Start von einem anderen Aufbau des Codes, bevor der test beendet wurde, oder so.
- Wenn Sie einige Variablen in Ihrem CMakeLists.txt (wie Versionierung Variablen), dann benötigen Sie für die Erstellung Ihrer make-Datei jedes mal zu aktualisieren, Ihre Versionsverwaltung Variablen
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ja, du kannst es in einem Schritt.
Zum Beispiel in meinem Jenkins Umwelt beim Bau der Ubuntu-jobs verwende ich die CMake-plugin für die ganze Zusammenstellung, wie es ermöglicht verschiedene build-tool Aufrufe.
Meinem screenshot auf der Unterseite von diesem post ist von einem CMake-Schritt in einem job (ich benutze Ninja-statt Unix-Makefiles, aber der Effekt ist der gleiche).
Ich zwei bauen Aufrufe:
ninjaodermakein einer shell,DESTDIR=. ninja install.Wenn ich bauen wollte zusätzliche Ziele von makefiles, ich könnte nur hinzufügen, zusätzliche Aufrufe für diesen Schritt.
Hinweis, dass in deinem screenshot hast du eine leere Anrufung in der Konfiguration. Dies wird bereits Berufung
make, und bestätigt durch Ihre log-Ausgabe, Sie sind in der Tat kompilieren Sie Ihr Projekt zweimal aufgrund der manuellen Aufrufmake allim folgenden Schritt.Können Sie entfernen Sie Ihre shell-Schritt und Ihr Projekt wird immer noch bauen.
Bezüglich Ihrer Frage nach best practices und regenerierende CMake, ich Verweise Sie auf diesen Artikel auf Jenkins Best Practices, wo es heißt:
Beachten Sie, dass ich auch überprüfen "Clean Build" in meinen CMake-Schritt, so dass die gesamte CMake Arbeitsbereich ist ausgelöscht und das Projekt generiert wird, von Grund auf für jeden build. Dies gewährleistet, es gibt keine Probleme, die durch veraltete cache-Variablen, etc.
Screenshot von einem CMake-Schritt in eine meiner Aufgaben:
Ich bin mir nicht einmal sicher, benötigen Sie dieses plugin. ANMUTIGEN die plugin-Webseite ist nur dann nützlich, wenn Sie möchten, dass jenkins einen bestimmten cmake-version, oder Sie wollen eine GUI, für die cmake-Variablen, die Sie möglicherweise festlegen möchten. Ich habe gerade ausführen cmake von der Befehlszeile aus.
Für den zweiten Teil der Frage, Wenn Sie ändern CMakeLists.txt das Makefile wird automatisch erneut ausführen, cmake, also streng genommen ist es nicht notwendig, cmake jeder Zeit. Aber auf der anderen Seite cmake Konfiguration ist ziemlich schnell und wahrscheinlich weniger Zeit in Anspruch nimmt als kompilieren.
makeoder was auch immer von der Kommandozeile aus? Es wäre schön, wenn Sie könnten erweitern, dass mit einigen Referenzen.