GitLab CI integration

[Whookie]

Ich bin gerade dabei meine Projekte mit GitLab CI automatisch erstellen und testen zu lassen. Dabei habe ich einige 3rd Party libraries (TeeChart, mrMath, ...) einige eigene Libraries (zum Teil benötigen sie eine 3rd Party Lib) und dann natürlich die eigentlichen Projekte.

Problemlos lassen sich unabhängige Libs (und Projekte) erstellen. Der Plan wäre aber, dass ich alle benötigten Libraries als submodule in die Projekte einbinde. Testweise habe ich folgendes Testprojekt gewählt:

Code:

x:\..\<TestPrj>\src\*             <- Eigenes Projekt
x:\..\<TestPrj>\libs\mrMath       <- 3rd Party lib
x:\..\<TestPrj>\libs\mylibA       <- eigenständig
x:\..\<TestPrj>\libs\myLibMath    <- benötigt mrMath

Die Submodule sind passend eingebunden und werden auch von der CI ausgecheckt.
Grundsätzlich lassen sich auch alle Teile kompilieren ABER mir fehlt die Möglichkeit dabei auf die Pfade der libs zu verweisen das müsste ich ja, soweit ich das sehe über die Registry-Bibliothekspfade machen (?)? ... Damit wäre dann aber ja nur ein Projekt möglich?

Gibt es hier eine Möglichkeit bei msbuild zusätzliche include-pfade anzugeben?

[Uwe Raabe]

Zitat von Whookie:

Grundsätzlich lassen sich auch alle Teile kompilieren ABER mir fehlt die Möglichkeit dabei auf die Pfade der libs zu verweisen das müsste ich ja, soweit ich das sehe über die Registry-Bibliothekspfade machen (?)?

Du kannst doch für jedes Projekt weitere Suchpfade angeben, die denen aus der Registry vorangestellt werden.

[Whookie]

läuft!

Die Packages compiliere ich in der CI mit

Code:

 /p:DCC_DcpOutput=package_dcu_path"

. Damit landet die .dcp gleich bei den .dcu Dateien des Packages.

Beim Projekt (und Packages die eine andere Lib brauchen) verwende ich in der CI

Code:

/p:DCC_UnitSearchPath=lib_dcu_path

(laut Hilfe hätte ich das für einen Sourcecode-Pfad gehalten) damit läuft der Buildvorgang komplett durch.

Einzige Frage die momentan offen bleibt: Wie Machst du das mit unterschiedlichen Projekten in der IDE?
Ich habe da momentan klassisch "die aktuellen Librarys" in den Bibliothekspfaden (da auch mit RELEASE und DEBUG Pfaden). Eigentlich müsste ich jetzt ja vor jedem Projektwechsel die ganzen Libs in der passenden Version dort auschecken, alles builden und installieren und dann kann ich das Projekt zum Bearbeiten öffnen???

[himitsu]

Wie bereits erwähnt, kannst du diese Pfade auch in den Projektoptionen setzen,
dann stehen es wie gewohnt in der DPROJ und es ist immer gleich, egal ob die im CI oder der IDE kompilierst.

Du übergibst dem MSBuild doch die DPROJ und nicht DPR/DPK.


Willst du für CI andere Ausgabepfade/Optionen, dann erstell dir eine oder zwei OptionSets dafür.
z.B. unter Debug und Release oder daneben eine neue Konfiguration erstellen und z.B. CI nennen, welche du dann im CI auswählst. Darin dann das Gewünschte ändern, wie z.B. den Ausgabeplfad.

alternativ kann man auch ein externes OptionsSet (.optset) erstellen, darin zentral für CI das Gewünschte anpassen und dieses OptionsSet in allen Projekten verlinken (nicht importieren, damit es sich nachträglich auch zentral ändern lässt)


Debug und Release sind einfach nur Namen. Ich kann meine ReleaseConfig auch "Debug" oder "Hugo" nennen, wenn mir danach ist. Wichtig ist nur was darin eingestellt ist.

[Whookie]

Zitat von himitsu:

...Willst du für CI andere Ausgabepfade/Optionen, dann erstell dir eine oder zwei OptionSets dafür...

Das ist eine fantastische Idee, dass werde ich gleich mal ausprobieren!

Bleibt natürlich trotzdem das Problem, das unterschiedliche Projekte dann in Zukunft verschiedene Versionen der Libraries verwenden und der Projektumstieg zwischen den Projekten ein Problem darstellt.

[Uwe Raabe]

Ich habe bis auf ganz wenige Ausnahmen (z.B. CodeSite, weil es in der Regel nur lokal verwendet wird) gar keine Pfade auf Fremdbibliotheken in den globalen Bibliotheks-Pfaden. Insbesondere nicht auf dem Build-Server. Dort sind diese Bibliotheken auch nicht in der IDE installiert.

Für das Projekt gibt es bei mir im Wesentlichen folgende Ordnerstruktur:

<root>\source
<root>\lib
<root>\dcu
<root>\bin

source und lib sind in der Versionsverwaltung, dcu und bin sind durch das ignore ausgeschlossen.

Alle Projekte (dpr, dpk, dproj...) liegen in source, die Units in der Regel in sinnvollen Unterverzeichnissen davon. Das hat den Vorteil, dass ich Option Sets mit den relativen Suchpfaden für alle Projekte verwenden kann.

lib ist der Sammelordner für Bibliotheken, die jeweils als submodules darunter liegen.

Für Bibliotheken, die nicht als Source in den Projekten eingebunden sind, gibt es eine Batchdatei zur Erzeugung der DCU, DCP und BPL-Dateien. Die sorgt auch dafür, dass die DFM und RES Dateien in den DCU-Ordner kopiert werden. Das ist dann ein eigener Ordner unterhalb lib, der dann auch im Suchpfad des Projekts auftaucht. Ich verwende bewusst nicht den dcu-Output Ordner, da ich den häufig einfach mal lösche.

Suchpfade auf Bibliotheks-Sourcen werden durch passend benannte Option Sets eingebunden. Nicht alle Projekte verwenden alle Bibliotheken.

Unterhalb von dcu gibt es für jedes Projekt einen Unterordner mit der üblichen Platform/Config-Struktur. Der entsprechende Eintrag in den Projektoptionen dazu lautet ..\$(SanitizedProjectName)\$(Platform)\$(Config) und ist wieder für alle Projekte gleich.

[pustekuchen]

Hallo Uwe,

du erwähnst $(SanitizedProjectName). Ich habe versucht diese Variable über optsets in Anwendungen zu verwenden, jedoch scheint das nicht zu funktionieren. Der Wert der Variable ist immer Leer. Habe es ist einem Testprojekt mit 11.2 probiert.

Hast du dazu eine Idee? In der *.dproj Datei gibt es jedefalls den Eintrag <SanitizedProjectName>TestApplication</SanitizedProjectName>

[Uwe Raabe]

Sorry für die späte Antwort, aber ich bin erst gestern nach gut einer Woche aus dem Krankenhaus zurück und immer noch nur sparsam einsetzbar.

Die Variable ist in der Basis-Konfiguration definiert, aber leider nicht an erster Stelle. Einträge davor sehen also nur einen Leerstring.

Du kannst entweder die Verwendung auf die Childkonfigurationen verlagern oder meinen Project Magician verwenden und das Normalize für das Projekt aktivieren. Der sortiert das um.

[juergen]

Uwe, ich wünsche dir Gute Besserung und vollständige Genesung!

[pustekuchen]

Zitat von Uwe Raabe:

Sorry für die späte Antwort, aber ich bin erst gestern nach gut einer Woche aus dem Krankenhaus zurück und immer noch nur sparsam einsetzbar.

Die Variable ist in der Basis-Konfiguration definiert, aber leider nicht an erster Stelle. Einträge davor sehen also nur einen Leerstring.

Du kannst entweder die Verwendung auf die Childkonfigurationen verlagern oder meinen Project Magician verwenden und das Normalize für das Projekt aktivieren. Der sortiert das um.

Hallo Uwe,

auch von mir gute Besserung und danke für die dann doch schnelle Reaktion! Den Project Magician verwende ich bereits (Danke für das Tools, das hilft sehr!). Die Optsets kommen ja durch Imports rein. Diese sind teilweise VOR der Basiskonfiguration, aber ich konnte bereits beobachten, dass auch welche NACH der Basiskonfiguration + Sub-Konfigurationen sind (Trotz Project Magician). Das konnte ich mir auch nicht erklären, da ich davon ausgegangen bin das der Project Magician alle Imports gleich behandelt.