ein DevExpressVCL-Compiler

[Nathan]

Hallo zusammen
Den Kampf mit DevExpress haben wir auch. Bei uns ist es vom Projekt her so, das verschiede Versionen auch verschiedene DevExpress Versionen brauchen.
Bedeutet Delphi mal mit DevExpress 20 mal 21 usw.. Hiess immer DevExpress deinstallieren und installieren.

Um das zu beschleunigen, gehen wir hin und entfernen unter Windows, die globale Path Variable DXVCL nach einer Installation. Danach kommt die Umgebungsvariable DXVCL in die IDE als Umgebungsvariable. Bei jedem Wechsel, entfernen wir alle Einträge aus ..\SOFTWARE\Embarcadero\BDS\xx.0\Known Packages die mit DevExpress zu tun haben und schreiben sie neu auf die gewünschte Version. Wichtig ist, das die globale Umgebungsvariable weg ist, sonst sucht die IDE erst dort und passen die Versionen nicht zusammen geht nichts.

Was wir noch machen, sind Codeänderungen direkt in DevExpress Units. Führt dazu das man DevExpress immer neu kompilieren muss. Um das zu automatisieren, rufen wir das DevExpress Setup 2 mal auf. Einmal mit ..\DevExpress VCL\Setup\Setup.exe /M und einmal mit /C

/M (Modifiy) ist hier vor dem /C (zum Kompilierern) wichtig. Es bereinigt den Registry Eintrag "UserInfo" unter "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ Developer Express VCL Products". Das Setup prüft dort ob die "UserInfo" zu "Build" und "BuildCode" passt. Mit /M wird "UserInfo" angepasst. Wie der Eintrag "UserInfo" zusammengestellt wird, hat DevExpress nie verraten. Sie meinten das ich dort nichts zu suchen hab. Aber mit /M und auf die gewünschte DevExpress Version angepassten "Build", "BuildCode" Werten kann man das kompilieren mehr oder weniger automatisieren bzw. beschleunigen. Es wir immer noch alles kompiliert, aber man muss vorher nichts deinstallieren.

Manuell jedes Package kompilieren hatten wir auch überlegt, aber verworfen. Weil es viel zu viele sind und bei einer neuen Version muss man alle wieder zusammensuchen. Das Setup weiss das alles. Davon abgesehen, alle Packages zu kompilieren geht schon. Hab mal ein Github Repo angeschaut unter: https://github.com/Delphier/DxAutoInstaller was wir aber nie weiter verfolgt haben.

[himitsu]

Jo, 240 DevExpress-Packages, nochmal knapp über 80 eigene BPL/DLL/EXE und einige weitere Tools und zwei Hände voll kleinerer Fremdkomponenten (FastReport, pgDAC und mehr).



Einmal muß tut auch der Master nicht mit dem aktuellen Release übereinstimmen,
sowie nich alte Branches und vor allem auch alte Release-Branches.

Es muß also auch möglich sein eine andere/alte Version auszuchecken und neu zu kompilieren, mit den jeweils dazu passenden Versionen der Externen-Komponenten. (das war mit deren Setup praktisch unmöglich)
Anderen Branch/Commit auschecken, im FinalBuilder bei "externe kompilieren" einen Haken setzen (wobei inzwischen der FinalBuilder den zuletzt kompilierten Commit-Hash mit dem Aktuellen vergleicht und es automatisch aktiviert) und fertig. (wenn sich an der PackageListe nichts ändert, müssen sie nicht unbedingt neu registriert werden)




Bis jetzt hatten wir auch jedes FremdKomponenten-Package manuell im FinalBuilder als Action eingetragen und dazu eine ListenVariable mit den "Packagname=Description" die in jeder Komponentengruppe addiert werden (bisher abgesehn vom DevExpress, das fehlte halt)
und am Ende läuft der FinalBuilder über diese Liste, registriert neue Packages und entfernt alte, sowie räumt die DisabledPackages auf usw.

Also DevExpress wurde (bisher) noch nicht im FB kompiliert, aber die Liste mit den Packages mußte manuell im FB aktualisiert werden, sowie in einer Variable die Requires. Diese Variable ist in allen DLL/EXE drin, damit sie auch die aktuellen DevExpress kennen.




Jupp, die globale DXVCL hab ich bei mir entfernt ... und wo deren Setup nie lief, fehlt die sowieso.

Im FinalBuilder als Projekt-Variable (Environment=True), sowie im Delphi in den "eigenen" Umgebungsvariablen (Tools->Optionen->Umgebungsvariablen, bzw. HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Environment Variables)
Dort hab ich die passende DXVCL jeweils eingetragen und hab so auch je Delphi die Möglichkeit eines anderen Wertes.

Sowie die Umgebungsvariable PATH ist noch geändert (leider ist es im Delphi nicht möglich %PATH% innerhalb des PATH zu benutzen, so dass der FinalBuilder den aktuellen System-Wert dort hart drin abspeichert)



Auch hab ich unser Projekt-Repo nun fast komplett mit relativen Pfaden, bzw. welche zur Laufzeit ausgewertet werden.
So ist es auch möglich mal in einem anderen Projektverzeichnis (Kopie) zu arbeiten ... dort dann nur einmal im FinalBuilder die Registrierung neu ausführen. (hab in den Delphi-Umgebungsvariablen inzwischen auch eine Variable $(root), welche schnell vom FinalBuider immer auf das aktuelle Arbeitsverzeichnis gesetzt wird ... so müssen nicht alle Registrierungen aktualisiert werden, wie z.B. auch der Favorit zum Projekt in der Willkommenseite, welches immer auf aktuelle/letzte Verzeichnis zeigt)

Auch wenn ich in letzter Zeit meistens im GIT switche, aber als ich letztens mitten im Merge in ein anderes Repo wollte ... da funktioniert der Stash leider nicht.

Zitat:

Was wir noch machen, sind Codeänderungen direkt in DevExpress Units

Genau, erst deren Setup und dort auf Recompile
Aktuell haben wir keine "eigenen" Änderungen im DevExpress, bzw. für die aktuelle Änderung hatten wir von DevExpress via Mail ein angepasstes Setup bekommen, zum Testen, bevor die den Bugfix ausrollen

[pustekuchen]

Hallo himitsu,

ich habe anfang dieses Jahr bei uns auch alle 3rd-Party Komponenten ins Git (GitLab) portiert und dort Pipelines eingerichtet, um alles von Grund auf zu bauen. DevExpress war da, aus den gegebenen Gründen, der Endgegner und ich habe das erst einmal nach hinten geschoben, weil es sehr aufwendig schien.

Alleine die richtige Reihenfolge der Packages zu ermitteln war schon katastophe. Danke, dass du dir die Mühe gemacht hast, das mal zu reverse engineeren Das wird sicherlich helfen, dass dann auch in unseren Pipelines abzubilden.

Denn wir haben aktuell auch die compilierten units im git, was das ganze total aufbläht, wegen der immensen größe. Ich werde mich da wohl bei Zeiten auch wieder mit beschäftigen und dank deiner vorarbeit das ganze portieren können.

Katastrophe ist auch, dass nicht $(AUTO) als Lib-Postfix genutzt wird, sondern die Packages explizit die Delphi Version im Namen haben.

[himitsu]

Jupp, darum hatte ich auch alle Codes mit hochgeladen, inkl. dem alten FinalBuilder.
So kann jeder sich in Ruhe auch was abgucken.

Zitat:

Reverse

Ob DevExpress das selbst automatisch bestimmt, oder einfach nur statische Listen benutzt ... k.A.
* der DxAutoInstaller hat auch einfach sortierte Listen in der einen INI ... wo man nach einem Update schauen muß, ob Diese noch stimmen
* und ins DelphiPI hab ich noch nicht geschaut (aber dort sollte nichts vom DevExpress direkt drin sein) ... die Beschreibung klang so, als wenn sie es hähnlich wie ich machen

Bezüglich $(AUTO) gibt es leider auch noch andere Probleme, bereits beim Delphi selber.
z.B. im PostBuildScript fehlt vom $(AUTO) das Prefix "280" in den Output-Variablen.
Und es gibt auch manchmal einen Unterschied zwischen InlineCompiler und MSBuild (einige der $(Intput)/Projekt/Output-Variablen sind machmal im MSBuild einfach leer, obwohl ihr Wert eigentlich in einer der C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\CodeGear.*.Targe ts generiert werden müsste, so als wenn der <Import> übersprungen worden wäre)

* im Prinzip erstmal alle nötigen ProjectDateien suchen "**\Projects\*RS28.dproj"
* dort die Requires auslesen
* und dann "nur" noch das Sortieren (hier hatte ich mehrmals 'nen Knoten im Hirn)
* * aber, wie gesagt, notfalls könnte man auch unsoriert kompilieren (siehe Beschreibung oben)