GitLab CI integration

[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