Subversion Revision in die Compilierung aufnehmen

[David Martens]

Folgende Situation:

Wir benutzen Jenkins als NightlyBuild Server um per Commandline unser Projekte täglich (kurz vor Release stündlich) zu erstellen.

Von einem anderen Entwickler wurde auf ein recht krude Art die rc-Datei jedesmal neu erstellt. Mit "svn info" Revision lesen, rc-Datei einlesen und 'VALUE "FileVersion"', 'FILEVERSION' und 'PRODUCTVERSION' auf x.x.x.SVNREVISION gesetzt. Das ganze natürlich mit grausigem AnsiPos und StringReplace.

Ich bin gerade dabei den ganzen Buildprozess von einer Batchdatei auf Python umzustellen. Am liebsten wäre mir eine Möglichkeit der dcc32.exe eine Version als Flag zu übergeben, aber das wird nicht gehen.

Für die IDE ist das alles nicht notwendig, da die Entwickler keine Exen bereitstellen sondern alles über Jenkins läuft.

Was mir jetzt vorschwebt ist eine vernünftige Komponente oder so mit der ich die rc-Datei aktualisieren kann. So das ich folgendes aufrufe: 'changeVersion.exe SVNREVISION Project.rc'

Die ResourceUtils hab ich mir schon angesehen und auch die PJResFile. Leider alle nur für *.res.

Wenn es nicht anders geht nehme ich auch die, aber damit hatte ich bisher keinen Erfolg.

[bernhard_LA]

ist bei XE der FinalBuilder mit dabei ? der kennt auch SVN actions und kann den delphi compiler steuern ... (http://www.finalbuilder.com/)

[himitsu]

Ja, bei XE ist eine abgespeckte Emba-Version des FinalBuilders bei,
aber für einen automatischen Build auf 'nem Server ist der nicht vorgesehn.

[jaenicke]

Zitat von David Martens:

Die ResourceUtils hab ich mir schon angesehen und auch die PJResFile. Leider alle nur für *.res.

Wenn es nicht anders geht nehme ich auch die, aber damit hatte ich bisher keinen Erfolg.

Da gibt es TPEResourceModule, mit dem man auch die .exe aktualisieren kann. Das ist aber gar nicht notwendig.
Ein fertiges Open Source Tool, das das damit macht, findest du hier:
http://www.jasontpenny.com/blog/2009...in-res-or-exe/

Wir machen das aber anders:
Ich schreibe die Version einfach im PreBuild-Event mit diesen Units in die .res Datei hinein. Dann kompiliert Delphi die gleich mit ein und ich brauche keine eigene .rc Datei. Heißt man kann die anderen Versionsinfos auch in Delphi normal editieren. (Und wenn man die Version nur an der letzten Stelle ergänzt, geht das sogar mit der restlichen Version.)

[Phoenix]

Das ist aber alles ziemlich umständlich :-/

1.) Wieso Batch-files oder noch schlimmer Scripte in anderen Sprachen zum bauen?
Delphi verwendet intern MSBuild, und es gibt keinen Grund um diese sehr umfangreiche und mächtige Build-Plattform noch irgendwas drumrum zu bauen. Was man mit MSBuild nicht hinbekommt, bekommt man auch nicht anderen Scripten hin.

2.) http://thekindofme.wordpress.com/200...-build-target/
Das ganze baut auf den MSBuild Community Tasks auf, die es auf Codeplex gibt.
Diese Tasks sind Erweiterungen für MSBuild und in dem Beispiel hier wird gezeigt, wie man die SVN Revision in eine MSBuild-Variable (heisst dort Property) ausliest und mittels des FileUpdate-Tasks in eine beliebige Datei schreibt (hier mit einer Replace-Regex).

Das ganze wird vor dem eigentlichen Build durchgeführt (hier passiert ein bisschen magic durch den Namen des targets).

[jaenicke]

Und warum sollte man die Build-Events, die ja immerhin auch in dem MSBuild-XML drin stehen, nicht benutzen?

Zu dem Beispiel:
Klar könnte man die Revision auf dem Weg in eine .rc Datei schreiben, die man dann kompilieren kann. Das wäre aber dann von hinten durch die Brust ins Auge, weil man dann die Versionsinformationen nicht mehr in Delphi verwalten kann.

Deshalb sehe ich keinen Vorteil darin herumzutricksen, statt direkt per Programm die Versionsinformationen zu aktualisieren (ohne sie komplett selbst zu erstellen) und ansonsten alles standardmäßig zu behandeln...

[Phoenix]

Selbst das aufrufen eines externen Tools würde ich mit einem Execute-Task in einem eigenen Target machen. Hier kann man wenigstens noch saubere Fehlerbehandlung machen. Die Pre- und Post-Build Events sind zu Fehleranfällig, zu unflexibel und werden gerne für Dinge mißbraucht, die als eigenes Target viel einfacher zu realisieren (und auszuwerten!) sind.

Zudem kann man die Reihenfolge im Target beeinlussen. Pre- und Postbuild Steps passieren an zwei definierten Positionen ganz am Anfang und ganz am Ende, und lassen sich nicht ändern.

Ein Target kann man mittels beforeTargets / afterTargets genau dort in den Build-Prozess integrieren wo es Sinn macht: Zum Beispiel nur dann, wenn die ersten paar Targets schon durchgelaufen sind. Wenn MSbuild dann z.B. feststellt dass keine Files seit dem letzten Build geändert wurden, würden bestimmte Steps übersprungen und z.B. direkt zum Linken übergegangen (spart einiges an Zeit). Wenn ein Pre-Build Event nun aber das File immer ganz am Anfang anfasst, wird auch immer komplett neu gebaut.

Das heisst durch den falschen Gebrauch dieser Pre- und Post-Build events sorgt man ohne es zu wissen gerne für einen ordentlichen Zeitverlust und sorgt dafür, dass bestimmte andere Features in MSBuild nicht mehr funktionieren.

Generell sind Pre- und Post-Build Events also eher in der Kategorie 'potentiell Böse. Sollte man nur Nutzen wenn man *genau* weiss, was man damit tut' einzustufen.

[jaenicke]

Ich habe bisher an der MSBuild-Projektdatei nicht viel manuell gemacht. Bisher nutze ich nur die Features, die Delphi da auch anbietet.

Es funktioniert ja schon teilweise nicht mehr, wenn ich ein XE2 Projekt wieder mit XE öffne (XE stürzt ab). Da habe ich schon Bedenken was passiert, wenn ich da auch noch manuell drin bastele.

Werden solche zusätzlichen Targets denn auch korrekt abgearbeitet, wenn ich ein Projekt aus Delphi heraus starte?

[Phoenix]

Auch die IDE triggert nur MSBuild im Hintergrund an, von daher sollte das passen.