Continuous Integration inkl. Cross Compilation FÜR x86/Win32

[Top-OR]

Moin Freunde der gepflegten Programmierung.

Ich brauche heute eure Inspiration!

Also: Ich entwickle an einem Projekt, dessen Target x86, Win32 + OpenGl ist. Etwas anderes ist erstmal nicht geplant

Zur Codeverwaltung benutze ich ein Git, welches (u.A.) auf einem kleinen Homeserver ("bare repo" auf einem Raspberry Pi) läuft.

Berufmäßig bin ich im OSS Enterprise-Umfeld mit Java unterwegs.

Know your foe und so... Naja .. man kann davon halten, was man will. Ein riesiger Javaliebhaber bin ich auch nach Jahren noch nicht geworden.

Allerallerdings; um mal mit Onkel Hotte zu sprechen; schiele ich schon seit Jahren/Monaten neidisch auf das Build-System, welches die Jungs aus der Javawelt in der Firma benutzen - inwzischen hat sich das hier gut etabliert.
Der Code wird hier in einem SVN verwaltet (ein RIESEN-MAMMUT - fragt nicht). Ein Post-Commit-Hook triggert einen Jenkins, der aus den Javasourcen (Liferay) dann lustige Plugin-Artefakte baut und sie in ein Repository (Artifactory) steckt.
Gebuildet wird hier noch mit ANT, das Dependency-Management wird mit Ivy gemacht (was im Grunde auf Maven-Strukturen zugreift).


Ich hätte sowas gerne auch für meinen privaten Krams aus der guten C++-Welt. Ich will Continuous Intergration (gerne erstmal ohne Unit-Tests):

Use Case: Ich würde gerne lediglich einchecken und ein paar Minuten später mein fertiges Artefakt, die .EXE bzw. Lib, (sofern es gebaut werden konnte) aus einem Repository ziehen.

Hat jemand sowas schonmal in überschauberen Rahmen für C++ gemacht? Geht das, ohne dass man Monatelang frickeln muss und dann doch wahnsinnig wird?

Es geht mir hier eher um Inspiration.

Hat jemand sowas von euch schonmal gemacht?

Welche Toolchain seht ihr dafür?

Ich builde für Windows32 mit X86, möchte es aber am liebsten auf der Linux-Büchse (ARM-CPU) bauen lassen - auch wenns da 10x so lange dauert. Der bekommt auch Zeit von mir.

Dazu müsste ich mich ja mit Crosscompiling ARM/Linux für x86/Win32 auseinandersetzen.

Abhängigkeiten im Code habe ich wenig: Lediglich plain win32 und OpenGL. Perspektivisch muss ich mich auch mal mit 64 Bit beschäftigen.

Kann mir jemand mal ein paar Buzzwords hinwerfen, womit man sich da mal an Tools beschäftigen könnte?

Jenkins soll ja auch mit C++ funktionieren. Das Selbe habe ich von x anderen potentiell interessanten Tools gelesen.

Gibts hier Erfahrungswerte, die jemand teilen mag?

Was ist bei uns C++-Peoples wirklich cool, was Continuous Integration mit Cross Compilation angeht?

[RustySpoon]

Wir benutzen auch Jenkins und sind so semiglücklich damit. Einer unserer Kunden schwört auf TeamCity, wenn das lizenzrechtlich für dich kein Problem darstellt, würde ich mir den mal anschauen.

[NytroX]

Hi,

also ich habe schon diverse Build-Toolchains mit ANT gebaut.
Aber die Tools an sich machen ja erstmal garnix (Ant, Maven, Ivy), da muss man ja erstmal ein wenig dran rum basteln.
Wenn du was ganz einfaches haben willst, würde ich einfach Ant nehmen und die Toolchain da zusammenhängen.

Gerade bei C++ würde ich aber unbedingt empfehlen auf der entsprechenden Target-Platform zu bauen.
Also auf Linux/ARM eine Windows EXE zu bauen halte ich für Quatsch, das magst du vielleicht mit super-viel gefrickel und Cross-Compiler-Gedöhns irgendwie hinkriegen, aber das wäre mir persönlich zu blöd/zu viel Aufwand.

Hudson an sich macht auch erstmal nix; es startet nur ein build (z.b. Ant-Script) auf einer Maschine mit einem Buildbot.
Der Buildbot liegt ideallerweise auf der Target-Architektur; der Hudson Server ist egal wo du ihn hinpackst.

Wenn du C++ Code hast, der platformunabhängig ist, kannst du dann z.B. einen Buildbot auf Linux und einen auf Windows haben, und dann entsprechend dort compilen.
Dabei empfiehlt es sich, ein Tool wie CMake oder sowas als Zwischenschritt in der Toolchain zu haben, sonst musst du die ganzen Configs doppelt und dreifach schreiben.

Dann kannst du in egal welcher IDE entwickeln und sobald du eincheckst baut der Hudson mit Hilfe der Buildbots die Executables auf allen Architekturen parallel und checkt die Artefakte ein.

Wenn du wirklich Cross-Compilen willst würde ich das in einem 2. Schritt machen; erstmal alles irgendwie zum Laufen kriegen :-)

[Top-OR]

Moin RustySpoon und NytroX!

Danke für euren Input.

CMake habe ich schon im Einsatz. Sonst würde ich wirklich blöde werden, wenn ich für jedes Buildsytem/IDE etrax Build-/Projektfiles schreiben müsste.

Zum Thema Cross Compilation: Gestern Abend habe ich ein wenig mit mingw32 unter ARM/Linux rumgespielt.
Es macht mich ganz zuversichtlich, dass ich die Crosscompilation auch auf dem ARM ohne großes Gefrickel kompiliert bekomme.
Die ersten Libs meines Projektes, welche (zugegeben) recht systemunabhängig sind (Datenstrukturen, Mathekrams) habe ich gestern bereits erfolgreich kompiliert.

Dass ich nicht drumherum komme, den Build selbst zu scripten (sei es mit ANT oder einfachen Shellscripten), habe ich mir schon gedacht. Ich denke, fürs aller erste werde ich es erstmal bei Shellscripten belassen.

Dass der Hudson/Jenkins im Prinzip nur ein Frontend/Sheduler für andere Tools ist, ist mir auch klar. Ist halt ein cooles "Dashboard" in meinen Augen.
Nur, wie hoch der Aufwand ist, diese einzubinden, kann ich noch nicht abschätzen.
Ich hab kein Gefühl dafür, wie aufwändig es ist, son Ding für meine Zwecke zu konfigurieren... :-/

So richtiges Dependency Management für den Code sehe ich mich noch nicht machen (Ivy, Maven). Cool wärs perspektivisch schon. Ich hab zwar kaum Abhängigkeiten auf Externen Code, aber zumindest Abhängigkeiten auf interne Libs (Code oder Binaries in einem Repo - wenn ich eins hätte).

Was würdet ihr mir empfehlen, um die Artefakte zu speichern?
Ich denke da nicht nur an Code-Binaries (Exe, Dll, etc), sondern auch an Multimedia-Asssets für das Projekt (Bilder, Models, etc).
Ich hätte dazu auch gerne ne Art Versionskontrolle bzw. History.

Gibts da was "Tolles Fertiges", oder werde ich ein Script schreiben, was tar/gzip-Files mit Timestamp im Dateinamen erstellt und sie in eine lustige Directory-Struktur einsortiert?

[Chromanoid]

Was würdet ihr mir empfehlen, um die Artefakte zu speichern?
Ich denke da nicht nur an Code-Binaries (Exe, Dll, etc), sondern auch an Multimedia-Asssets für das Projekt (Bilder, Models, etc).
Ich hätte dazu auch gerne ne Art Versionskontrolle bzw. History.

Ich würde da strikt zwischen Quelldaten und fertigen Artefakten unterscheiden. Alle Quelldaten gehören ins Repository und alle Artefakte in ein Artefakt Repository. Frei nach Maven Assets also nach /src/main/assets (o.Ä. evt. auch src/main/resources, je nach dem was mit den Sachen gemacht werden muss), Code nach /src/main/cpp usw. (siehe auch http://maven.apache.org/guides/introduc ... ayout.html), auf jeden Fall alles unter "src" :D

Gibts da was "Tolles Fertiges", oder werde ich ein Script schreiben, was tar/gzip-Files mit Timestamp im Dateinamen erstellt und sie in eine lustige Directory-Struktur einsortiert?

In der Java Welt würde ich einen Blick in Sonartype Nexus oder JFrog Artifactory empfehlen...

Vielleicht kannst Du ja mal Gradle ausprobieren :) zumindest für das Publishen und wieder Abrufen von Artefakten in einen Artefakt-Server sollte das eine schnell einzurichtende Lösung sein.

[Schrompf]

Ich hab Exen wie Texturen oder sonstwas einfach eingecheckt. Zum Rest kann ich Dir leider wenig sagen, weil ich C++ immer auf dem schnellsten verfügbaren Rechner baue. Und das ist nunmal mein Desktop.

[Sternmull]

Als wir so was auf Arbeit gebraucht haben, hab ich mich für eine handgestrickte Python-Lösung entschieden. Das lag vor allem daran das ich kein Tool gefunden hab das mir so viel abnimmt das sich der Integrationsaufwand in dieses Tool lohnt. Das läuft nun schon seit einigen Jahren wie es soll.

Die Build-Ausgaben werden einfach als Dateien abgelegt. Normalerweise werden die alten Ausgaben gelöscht wenn neuere vorliegen. Ausnahme sind Tags im Git: Die entsprechen normalerweise einem Release-Candidate oder einem richtigen Release. Deshalb werden die dauerhaft aufgehoben und für die werden auch die PDBs in einen Inhouse-Symbol-Server eingetragen damit sich das Zeug bequem debuggen lässt. Wenn man alles für jeden Build aufheben würde, dann hätte man ganz schnell eine riesige Datenmenge die zu 99% aus Build-Ergebnissen von Zwischenversionen besteht die man sich nie wieder braucht.

Die Abhängigkeiten sind schon recht komplex. Es gibt halt C++ Quellen die gebaut werden, eine Installation die diese Quellen verwenet, Doxygen-Ausgaben die aus den C++ Quellen kommen, Tests die (nach ausführung des frisch gebauten Setups) in einer VM ausgeführt werden, Skripte die mit Tools aus dem C++-Build kompiliert werden, usw. Dazu kommt noch das verschiedene Branches verschiedener Repositories einem sinnvollen Sammelsorium zusammen gefasst werden, so was nenne ich "Buildset". Von den Dingern gibts für jede relevante Zusammenstellungen eins: Aktuelle Entwicklungsversion in der primär gearbeitet wird, dann noch diverse ältere Versionen die weiterhin unterstützt werden müssen und gelegentlich mit Bugfixes versorgt werden.
Das Skript nutzt diese Abhängikeiten natürlich um nur das Zeug zu bauen wo sich etwas getan hat.

Ereignisse und Status werden von dem Ding per Mail und Logdateien gemeldet, die User-Experience is also etwas roh. Insgesamt hat sich der Ansatz aber bewährt.

Wenn allerdings jemand ein nettes Tool kennt was die Abhängikeits- und Schedudiling geschichte mindestens ebensogut kann, und gleichzeitig noch ein nettes Web-Interface bietet auf dem Status und Logs übersichtlich dargestellt sind, dann würde ich mich sehr dafür interessieren.

[Chromanoid]

Wenn allerdings jemand ein nettes Tool kennt was die Abhängikeits- und Schedudiling geschichte mindestens ebensogut kann, und gleichzeitig noch ein nettes Web-Interface bietet auf dem Status und Logs übersichtlich dargestellt sind, dann würde ich mich sehr dafür interessieren.

Jenkins ist da sicher einen Blick wert. Die Lösungen, die man sich damit zusammenbaut haben IMO allerdings immer ein bisschen den Geruch des Selbstgestrickten.

[Top-OR]

Hallo Chromanoid, Schrompf und Sternmull.

Viele Anreize und Gedanken sind hier hute reingeflossen. Ich versuche mal zu extrahieren:

1)
@Chromanoid
Also Code und Artefakte und Assets möchte ich schon trennen. zur Not die letzen beiden in eine Gruppe, aber am liebsten alle drei.

@Schrompf: WO hast du denn deine Assets eingecheckt? Ins Git/SVN? Du kannst auch flüstern, dass die anderen es nicht hören. Zumindest habe ich diesen Hanstand nicht vor.
Ich will schon ein Repo, was halbwegs gut mit Binaries unmgehen kann. Oder kann man da inwzischen auch ein Git vergewaltigen?
SVN hat ja, soweit ich weiß, den Krams zeilenweise verwaltet. Da sind Binaries, die man da reinkippt, ja der Gau.
Wenns ein Repo gibt, was Binaries gut blockweise verwalten kann, könnte man sichs ja mal ansehen.

Ansonsten tendiere ich bei Binary-Repo zu was Selbstgestricktem oder vielleicht Artifactory - weil ichs (als User) kenne. Nexus gucke ich mir auch mal an.


2)
@Chromanoid
Fürs Bauen an sich wirds wohl auch enweder Jenkins oder was Selbstgebautes (CRON + Shellscripte).
Im Jenkins kann man im Grunde per Script eh alles abfackeln.

Es geht eh weniger um die Zusammenarbeit eines riesigen Teams, denn ich bin alleine.
Mir gehts eher darum, mal ein System in das Ganze bauen und integrieren zu bekommen.

In Zukunft könnte villeicht auch mal automatisiertes Testen interessant werden ... aber das ist ein ganz anderes Universum.

3)
@Sternmull
Danke für den schönen Umriss eures Systems.

Ich denke, es wird alles in allem noch sehr viel "eigene Software"(-elemente) werden, egal zu welcher Lösung ich greifen werden...

[Schrompf]

Ich hab bei mir alles ins SVN gekippt. Binärdateien werden erkannt und als Blob gespeichert - mergen geht da natürlich nicht mehr, aber dafür können die Grafiker auch damit arbeiten und wer auscheckt, kriegt das komplette lauffähige Spiel mit allen Daten. Alle Profis, bei denen ich bisher gearbeitet habe, haben das übrigens auch so gemacht.

[Top-OR]

Ich hab bei mir alles ins SVN gekippt. Binärdateien werden erkannt und als Blob gespeichert - mergen geht da natürlich nicht mehr, aber dafür können die Grafiker auch damit arbeiten und wer auscheckt, kriegt das komplette lauffähige Spiel mit allen Daten. Alle Profis, bei denen ich bisher gearbeitet habe, haben das übrigens auch so gemacht.

Echt? Erkennt der die Binaries? Cool ... ich glaube, dann mach ich mir keine grosse Waffel, was das Storage von den Binaries angeht:
Ich werde ein separates Repo für die Bins anlegen und jut is.

Ich bin ja kein Konzern, bei dem 100 Entwickler an einem Projekt arbeiten und den Überblick behalten müssen.
Mir gehts nur um ein "bissel Versionskontrolle" für die Binaries.

[hagbard]

Also ich kenne dass so das man pro Zielplattform einen Buildserver hat. Jenkins ruft dann entsprechende Custom-Build Steps und Post-Build-Steps auf (z.B. verpacken und auf einen bestimmten Ort ablegen). Jenkins unterstützt auch ein Maser-Slave-Konzept mit verschiedenen Nodes wenn man das braucht ich hatte noch nie Zeit mich damit zu beschäftigen. Wenn du mehrere Plattformen unterstützt wirst du aber um eine bischen Skripterei nicht umhin kommen dass dir die Plattformabhängigkeiten wrappt, sonst wird das mit den Buildjobs irgendwann der Maintainance Horror ab einer gewissen Anzahl.
Zum Verwalten von Abhängigkeiten unter C++ würde mich auch eine standardisierte Lösung interessieren. Ich habe da bisher nur immer jeweils selbstgestrickte Skriptsammlungen in verschiedenen Firmen gesehen. Nichts davon würde ich ernsthaft weiter empfehlen.

[Top-OR]

Ich würde da strikt zwischen Quelldaten und fertigen Artefakten unterscheiden. Alle Quelldaten gehören ins Repository und alle Artefakte in ein Artefakt Repository. Frei nach Maven Assets also nach /src/main/assets (o.Ä. evt. auch src/main/resources, je nach dem was mit den Sachen gemacht werden muss), Code nach /src/main/cpp usw. (siehe auch http://maven.apache.org/guides/introduc ... ayout.html), auf jeden Fall alles unter "src" :D

JETZT schnalle ich, warum du nochmal explizit auf die Trennung von Code und Binaries hinweist. Es war DIES hier, oder:

... Code oder Binaries in einem Repo - wenn ich eins hätte ...

oder? Ich meinte das:
... Code (in seinem althergebrachten Repo [Git]) oder Binaries in einem (eigenen dafür vorgesehenen) Repo (ohne Code) - wenn ich eins hätte ...

Hach, diese natürlichen Sprachen. Furchtbar.

Nenee,alles jut! Code und Bins trennen. Is schon klar...

[Top-OR]

Also ich kenne dass so das man pro Zielplattform einen Buildserver hat. Jenkins ruft dann entsprechende Custom-Build Steps und Post-Build-Steps auf (z.B. verpacken und auf einen bestimmten Ort ablegen). Jenkins unterstützt auch ein Maser-Slave-Konzept mit verschiedenen Nodes wenn man das braucht ich hatte noch nie Zeit mich damit zu beschäftigen. Wenn du mehrere Plattformen unterstützt wirst du aber um eine bischen Skripterei nicht umhin kommen dass dir die Plattformabhängigkeiten wrappt, sonst wird das mit den Buildjobs irgendwann der Maintainance Horror ab einer gewissen Anzahl.
Zum Verwalten von Abhängigkeiten unter C++ würde mich auch eine standardisierte Lösung interessieren. Ich habe da bisher nur immer jeweils selbstgestrickte Skriptsammlungen in verschiedenen Firmen gesehen. Nichts davon würde ich ernsthaft weiter empfehlen.

Entspricht ungefähr meinem Bild der Lage. Wobei es mir nur darum geht, ein wenig Ordnung in die wilde Code-Bauerei und Asset-Integrirerei und -Verwaltung zu bringen...

[NytroX]

Wobei es mir nur darum geht, ein wenig Ordnung in die wilde Code-Bauerei und Asset-Integrirerei und -Verwaltung zu bringen...

Ja, ich glaube genau da wäre der Ansatzpunkt.

In Firmen muss man den ganzen entwickelten Quatsch ja auch ausrollen, Versionen verwalten, bei Fehlern zurückrollen, uvm, d.h. Artifactory o.ä. macht da total Sinn.
Wenn du aber privat was entwickelst und vor jedem Test erstmal 2GB auschecken musst, macht das vermutlich keinen Spaß. :?

Ich würde mir genau überlegen, was du für DICH brauchst. Empfehlen kann man viel, aber die Frage ist halt ob sich der Aufwand dafür lohnt.
Vielleicht willst du ja auch mal nur Teile kompilieren, was ja z.B. ein VisualStudio einfach machen kann, und nicht immer gleich die ganze Maschinerie im Hintergrund anwerfen.
Macht es vielleicht Sinn, den "großen Hammer" nur für eine Art "nightly build" zu benutzen, wo du dann auf allen Platformen baust?

Die Frage wäre also: welches Problem versuchst du konkret zu lösen?
Oder anders formuliert: Wie sieht bei dir "wilde Code-Bauerei und Asset-Integrirerei" aus? :mrgreen:

[Sternmull]

Ein Repo das eine Historie der Build-Outputs verwaltet halte ich nicht für besonders sinnvoll. Das Problem ist halt wie gesagt das der allergrößte Teil dieser Ausgaben nach dem nächsten Commit schon wieder obsolet ist. Nur für besondere Versionen will man das Zeug permanent aufheben (mindestens Releases). Bei uns sind allein die Debug-Symbole dieser Versionen schon so groß das ich da hin und wieder mit dem Admin drüber reden muss. Dazu kommen dann noch die Setups, etc. das sind ganz schnell viel zu viele Daten.

[Chromanoid]

Nenee,alles jut! Code und Bins trennen. Is schon klar...

Dann ist alles gut :)

Ich würde Sternmull aber recht geben, sowas wie Nexus für ein eigenes Solo-Projekt ist ziemlicher Overkill. Solange Du nicht Spaß dran hast solche Technologien auszuprobieren, reicht es doch eigentlich wenn das Build reproduzierbar ist und Du für Release-Versionen ein Tag in Deinem SCM System anlegst. Dann brauchst Du immer nur das neuste aufheben. Da reicht dann ja auch ein Ordner, der vor jedem Build geleert wird.

[Top-OR]

Nenee,alles jut! Code und Bins trennen. Is schon klar...

Dann ist alles gut :)

Ich würde Sternmull aber recht geben, sowas wie Nexus für ein eigenes Solo-Projekt ist ziemlicher Overkill. Solange Du nicht Spaß dran hast solche Technologien auszuprobieren, reicht es doch eigentlich wenn das Build reproduzierbar ist und Du für Release-Versionen ein Tag in Deinem SCM System anlegst. Dann brauchst Du immer nur das neuste aufheben. Da reicht dann ja auch ein Ordner, der vor jedem Build geleert wird.

Naja, ein bisschen administratives Frickeln ist ab und an mal schön. Aber wenns jetzt ein Reisenprojekt wird, werde ichs wohl auch erstmal lassen.
Ich denke, ich werde mal mit Git als Repo und ein paar Build-Scripten herumspielen. Ob ich die später nun an nen Jenkins oder einfach nur Cron hänge, wird sich zeigen...

Danke allen soweit für die Meinungen: Wem nochwas einfällt, der zögere bitte nicht, hier was reinzuklimpern.