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:

Zitat von Whookie (Beitrag 1512935)

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]

:thumb: 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:

Zitat von himitsu (Beitrag 1512950)

...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! :thumb:

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

Delphi-Quellcode:

..\$(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:

Zitat von Uwe Raabe (Beitrag 1514514)

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.

[Uwe Raabe]

Kannst du mir mal so eine dproj mit den optsets schicken? Ich weiss nur nicht, wann ich dazu komme. Kann Weihnachten werden.

[pustekuchen]

Es ist echt frustrierend.

Delphi-Quellcode:

$(SanitizedProjectName)

kann man nicht in optsets verwenden, da diese Variable beim Laden noch nicht existiert.

Mit $(MSBuildProjectName) bekommt man das Projekt zwar compiliert, jedoch kann man dann nicht mehr debuggen:
https://quality.embarcadero.com/browse/RSP-38952
https://quality.embarcadero.com/browse/RSP-40471
https://quality.embarcadero.com/browse/RSP-40472

Das sind einfach schon drei Bugs, die einem aufhalten, eine saubere CI/CD Umgebung aufzubauen.
Wozu bezahlt man eigentlich noch teure Lizenzen, wenn die grundlegendsten Dinge nicht funktionieren.

[Uwe Raabe]

Zitat:

Zitat von pustekuchen (Beitrag 1518040)

Das sind einfach schon drei Bugs, die einem aufhalten, eine saubere CI/CD Umgebung aufzubauen.
Wozu bezahlt man eigentlich noch teure Lizenzen, wenn die grundlegendsten Dinge nicht funktionieren.

Also das ist doch jetzt wirklich maßlos übertrieben! Die Variable $(SanitizedProjectName) ist nicht mal dokumentiert, noch für die von dir vorgesehene Verwendung gedacht. Die Kombination OptSet und SanitizedProjectName gehört wohl auch eher in den exotischen Bereich. Ich bin ziemlich sicher, dass man dieses Szenario bei Embarcadero nicht auf dem Schirm hat.

Intern hatte ich schon angeregt, die Variable bereits in der ersten PropertyGroup zu deklarieren, wo auch MainSource drin steht. Dann würde das auch mit den OptSets klappen. Vielleicht baue ich das irgendwann mal in den Project Magician ein.

Dass $(MSBuildProjectName) von der IDE, insbesonder dem Debugger, nicht aufgelöst werden kann, da es von MSBuild intern gesetzt wird, kann man Delphi kaum anlasten.

Zu den C++ Problemen kann ich nichts sagen, da ich diese Personality nie verwende. Aus diesem Grund gehört C++ auch nicht zu den von Project Magician unterstützten Zielen. Wenn's klappt ist es gut, wenn nicht dann eben nicht.

Ich kenne persönlich aber eine ganze Reihe von Delphi-Installationen, die problemlos in CI/CD Umgebungen laufen. Einige davon habe ich selbst eingerichtet.

[pustekuchen]

Zitat:

Zitat von Uwe Raabe (Beitrag 1518041)

Also das ist doch jetzt wirklich maßlos übertrieben! Die Variable $(SanitizedProjectName) ist nicht mal dokumentiert, noch für die von dir vorgesehene Verwendung gedacht. Die Kombination OptSet und SanitizedProjectName gehört wohl auch eher in den exotischen Bereich. Ich bin ziemlich sicher, dass man dieses Szenario bei Embarcadero nicht auf dem Schirm hat.

Wahrscheinlich bräuchte man

Delphi-Quellcode:

SanitizedProjectName

auch gar nicht, wenn man

Delphi-Quellcode:

MSBuildProjectName

problemlos nutzen könnte.

Zitat:

Zitat von Uwe Raabe (Beitrag 1518041)

Intern hatte ich schon angeregt, die Variable bereits in der ersten PropertyGroup zu deklarieren, wo auch MainSource drin steht. Dann würde das auch mit den OptSets klappen. Vielleicht baue ich das irgendwann mal in den Project Magician ein.

Vielen Dank dafür.

Zitat:

Zitat von Uwe Raabe (Beitrag 1518041)

Dass $(MSBuildProjectName) von der IDE, insbesonder dem Debugger, nicht aufgelöst werden kann, da es von MSBuild intern gesetzt wird, kann man Delphi kaum anlasten.

Wenn die MSBuild-Variablen generell nicht unterstützt werden würde, wäre das ja noch zu verstehen. Aber nicht, wenn an einer stelle die Unterstützung da ist und an der anderen stelle dann wieder nicht.

[himitsu]

Mit MSBuild allgemein hab ich auch noch einige Problemchen.

Sowas wie $(OutputFileName) ist im AfterBuildScript öfters mal garnicht gesetzt und demnach leer, wenn man es dort verwendet,
obwohl eigentlich in einem in der DPROJ eingebundenen Script (CodeGear.Delphi.Targets, CodeGear.Common.Targets) gesetzt und auch geprüft wird, ob es gesetzt ist.

Warum es nicht geht, weiß ich nicht.
Als Bugfix generiere ich im FinalBuilder die fehlenden Variablen und übergebe sie als Parameter ans MSBuild.
Meine Vermutung war, dass er die *.target aus irgendeinem Grund nicht einbindet, was gut sein kann, da diese <Import>'s nur bei einem Exists macht.



Was aber auch noch ein perverser Bug ist, dass bei DllSuffix $(Auto) die Versionsnummern nicht in den Variablen $(OutputFileName) drin stehen, sowohl im InlineCompiler, als auch im MSBuild.
Also er erzeugt eine meine280.bpl, aber in den Variablen steht was von meine.bpl :wall:
Und außerdem hat Delphi nirgendwo eine Variable/Konstante/Registryeintrag, wo diese Nummern auslesbar sind.

[Uwe Raabe]

Zitat:

Zitat von pustekuchen (Beitrag 1518046)

Wenn die MSBuild-Variablen generell nicht unterstützt werden würde, wäre das ja noch zu verstehen. Aber nicht, wenn an einer stelle die Unterstützung da ist und an der anderen stelle dann wieder nicht.

Na ja, die eine Stelle, wo es unterstützt wird ist eben MSBuild selbst während des Compile-Vorgangs. Das stellt diese Variable implizit bereit und der Compiler kann die dann auch nutzen. Weder der Debugger noch die IDE kann diese Variable sehen - wie auch.

Natürlich kann man diese MSBuild-Variablen innerhalb des Build-Prozesses nutzen, aber man kann dann nicht erwarten, dass das dann außerhalb des Build-Prozesses auch funktioniert. Selbst wenn man das jetzt für diese eine Variable implementieren würde, käme sicher bald die Frage auf: Warum nicht die anderen auch? Dann hätte man aber eine potentielle Abhängigkeit von der verwendeten MSBuild-Version. Das halte ich eher für kontraproduktiv.

Was in der Tat zu bemängeln ist: Die IDE bzw. der Debugger lösen $(SanitzedProjectName) auch nicht auf, wenn es im Ausgabepfad für die EXE steht. Das ist nicht ganz, was in RSP-38952 bemängelt wird, und RSP-37401 erwähnt es nur intern.

Ich habe daher mal zwei neue Reports eingestellt, die diese Themen gezielt ansprechen:
Accept $(SanitizedProjectName) in EXE path when debugging
Move $(SanitizedProjectName) definition to main PropertyGroup