ein DevExpressVCL-Compiler

[himitsu]

Haben bestimmt schon welche gemerkt, dass DevExpress ja offiziell nur mit deren eigenen Tool/Setup (neu)kompiliert werden kann.
Außerdem verschandelt das Setup dann die Registry.

Bei uns liegen alle Fremdkomponenten in einem GitRepo, bzw. darin ein erster privater Fork 'ner Fremdkomponente als SubModule, inkl RemoteAdd zum Original.
Der FinalBuilder richtet die Entwicklungsumgebung des Entwicklers ein, kompiliert alles und registriert die Packages und unsere Projekte im Delphi.
(nur DevExpress weigerte sich)

Fehlt jetzt eigentlich nur, dass man beim Upgrade die Quellcodes ohne Installieren aus aus dem DevExpress-Setup raus bekommt.



Urspünglich hatte ich mal angefangen im FinalBuilder (VBScript) die DevExpress-Packages zu kompilieren.
Der Support meinte mal, das Setup mache spezielle Dinge usw., drum könne man es nicht selbst kompilieren.
Also heimlich abgeguckt, wie die wirklich den DCC aufrufen und diese Settings übernommen. (siehe um die Variable dccoptions herum, im meinem VBS/Delphi)
VBS, weil es im FinalBuilder das am Besten integriert wurde, also hin-&her zwischen Script und FinalBuilder, inkl. Codevervolständigung usw. (für PowerShell und JavaScript fehlte so Einiges und das hauseigene Python sollte man nicht verwenden)
Aber das wurde immer langsamer, vor allem der Umgang mit Arrays ist im VBScript schon fast pervers.

OK, nun alles in ein Programm ausgelagert und noch bissl dran rumgespielt ....
tadaaaaaa, ein DevExpressCompiler.exe

* grundsätzlich kompiliert er in der selben struktur, wie das Original
* nur ich kompiliere permanent mit DebugInfos, aber Diese als Externe TDS, welche standardmäßig in einer ZIP landen
* entpacken und schon kann gedebuggt werden, auch nur einzelne Packages

* für TestComplete brauchten wir eh die DebugInfos, was also ursprünlich im Setup zwei mal Kompilieren und Dateien dazwischen umkopieren hieß,
weil im Delphi will ich (meinstens) nicht beim Debugging in deren Sourcen landen und dort nie wieder raus finden. (Debuggen im DevExpress-Code ist fast so pervers wie im Eurekalog zu langen)


Bei uns im GitReop ist ein DevExpressVerzeichnis mit den Dateien aus den beiden Installationsorten,
C:\Program Files (x86)\DevExpress\VCL
C:\Users\Public\Documents\DevExpress\VCL\Demos
siehe die .\DevExpress\Sources-Update.cmd
da "noch" inkl. dem manuellen Kompilieren der paar Packages für TestComplete


.\DevExpress\VCL\Library\_Debugging ist ein Sammelverzeichnis, damit für den Debugger nicht zweimillionen Sources-Verzeichnis alleine vom DevExpress geristriert werden müssen.

Kompilieren tut das DX-Setups normal ins .\DevExpress\VCL\Library\ (steht im GitRepo auf ignore)
und der FinalBuilder kopiert dann alle Fremdkomponenten in gemeinsame Verzeichnisse für BPL, DCP und DCU/RES/DFM, bzw. was er FB selbst kompiliert, das direkt dahin.

.\DevExpress\VCL\Library\RS**\_DebugInfosDX.zip sind die optionalen DebugInfos (TDS und RSM, zuzüglich MAP und DRC ... mir fällt grade auf, das die D fehlt, aber egal)

In diesen BuildVerzeichnissen in den Zips die Logs usw. (hab hier bissl ausgemiste, also nur teilweise die Sourcen, sowie die Kompilate als 0 Byte)
.\DevExpress\VCL\Library\RS28\_BuildLogsDX.zip (CFG und DCC32-Logs, das eigene Log, weitere Build-/Config-Infos [b]und[b] z.B. _cxBDEAdaptersRS28.error.log "hervorgehoben")


grundsätzlich, was ich mache
* ein paar Suchpfade zusammensuchen, weil deren Projekte sind einfach nur grauenhaft (gucken die überhaupt selber da mal in ihre Logs )
(ein paar Units in falschen Verzeichnissen, bissl was implizit von sonstwo gezogen, Requires vergessen und Units doppelt einkompiliert .............)
* alle benötigten Packages suchen
* dort die Requires auslesen (jaaaa, böses RegEx ... LLVM wäre mal geil)
* PackageListe nach den Requires sortieren
* und dann kompilieren
* und noch ein paar Dateien zu den erzeugten DCUs kopieren, also vor allem DFM und RES
(klar, man könnte die Packages auch unsortiert kompileren, wenn es knallt, das Package ans Ende der Liste und später nochmal versuchen, bis möglichst alles durch ist)

\DevExpress\VCL\Library\RS28\_BuildLogsDX.zip -> _BuildDX.log das Log, bzw. die Kopie der Konsolenausgabe, des DevExpressCompiler

DevExpressCompiler -?

Code:

DevExpressCompiler -Params...

-ide:    or %_ide%  = 22.0   (missing = latest Delphi-IDE)
-ver:    or %_ver%  = 28     (optional)
-DXVCL:  or %DXVCL% = %_extern%\DevExpress\VCL
-DXLIB:  or %DXLIB% = %DXVCL%\Library\RS%_ver%   (optional)
-BDS:    or %BDS%   = C:\Program Files (x86)\Embarcadero\Studio\%_ide%   (optional)
-isWin64            = compile only with DCC64 (instead of DCC32+DCC64)
-SearchPath:        = e.q. for AnyDAC_ComI_D15.dcp in XE

-ide:                     = latest Delphi-IDE
-ide:*                    = all Delphi-IDEs
-ide:"20.0 21.0 22.0"     = comma, semicolon, colon or space separated
-notStopOnFail            = do not stop on compile errors
-noDebugDir               = make no %DXVCL%\..\_Debugging   (combined files from all \Sources)
-noWin64                  = %DXLIB%\RS**\Win64
-doRegister               = register packages in delphi-ide
-ShortTest                = handle only the first 5 packages
-Help  or -?              = this help

-Param Value     -Param "Value"
-ParamValue      -Param"Value"
-Param:Value     -Param:"Value"
/Param ...

PS:

Vordefinierte Pfade / IDE-Suchfunktion gehn so nur für "neuere" Delphis, also in C:\Program Files (x86)\Embarcadero\Studio.
Ältere Delphis ab 2006 bis 10, wie z.B. XE, oder mit manuell abweichenden InstallationsPfaden, benötigen die Angabe des %BDS%.



aktuellste IDE kompilieren (z.B. wenn %DXVCL% durch DevExpress-Setup als globale EnvironmentVariable vorhanden)
DevExpressCompiler

aktuellste IDE vom Verzeichnis %DXVCL% nach %DXVCL%\Library\RS%_ver% kompilieren
DevExpressCompiler -DXVCL:"%_extern%\DevExpress\VCL"

aktuellste IDE von DXVCL nach DXLIB kompilieren
DevExpressCompiler -DXVCL:"%_extern%\DevExpress\VCL" -DXLIB:"%_extern%\DevExpress\VCL\Library\RS%%_ver%%"

vorgegebene Delphi-Version inkl. Package-Registrierung und nur Win32 kompilieren
DevExpressCompiler -ide:22.0 -DXVCL:"%_extern%\DevExpress\VCL" -doRegister -noWin64

für alle installierten Delphis kompilieren und darin registrieren
DevExpressCompiler -ide:* -DXVCL:"%_extern%\DevExpress\VCL" -doRegister

Beispiele: Delphi XE und 11 (Suchpfad wegen AnyDAC)
DevExpressCompiler -ide:8.0 -ver:15 -BDS:"C:\Program Files (x86)\Embarcadero\RAD Studio\%%_ide%%" -DXVCL:"%_extern%\DevExpress\VCL" -noWin64 -doRegister -SearchPath:"%_dcp%"
DevExpressCompiler -ide:22.0 -DXVCL:"%_extern%\DevExpress\VCL" -doRegister

[Sinspin]

Die DevExpress All-In-One-Demo verschandelt die Registry hin und wieder auch. Die hat uns nachgewiesenermaßen schon mehrfach alle Emba Einstellungen aus der Registry gelöscht.
Nach so einem Anschlag kann man zwar die Embaeinstellungen in der Registry wiederherstellen, aber DevExpress kann nicht mehr installiert werden und auch der Emba Installer geht nicht mehr. Weder deinstallieren noch Reperatur/Drüber installieren. War Delphi wärend das passiert noch offen, schießt es sich mit einem Lizenzfehler ab. (DevExpress stellt sich übrigens ahnungslos)

Keine Ahnung was das soll, aber es könnte sein das die Demo verwendet wird um "ilegale installation" zu beseitigen, oder was auch immer.
Wir zahlen jedenfalls jedes Jahr ein haufen Geld. ...um dann den Rechner runiert zu bekommen.
Jaja, wir haben Backups. Aber natürlich dann gerade kein aktuelles.

Du machst nur den Compiler nach?
Das ist zumindest ein Anfang, dann kann man eine existierende Installation auch mal auf einem anderen Rechner übersetzen. Sweet!

Ich bin mal gespannt wie lange es dauert bis du Besuch bekommst von den Leuten in den schwarzen Anzügen.

[himitsu]

Nja, "nach" .... eher Neubau.
Hatte nur getrackt wie die den DCC32 aufrufen, weil auf Nachfrage, ob man die Quellcodes pur (ohne Setup) bekommen und dann selber kompilieren kann, hieß es "geht nicht, weil ...".

Aber abgesehn von der unintuitiven Reihenfolge der 240 DX-VCL-Packages, ist da eigentlich nichts Besonderes dran. (abgesehn von den "Bugs", bezüglich falscher/fehlender Pfade zu ein paar Units)

Das Kompilieren des DevExpress selber ist garnicht so aufwändig.
siehe .\DevExpress\Sources-Update.cmd
Da hatte ich zuerst "selbst" Kompiliert, als ich rausfand, was zu tun ist. (allerdings nur für eine Hand voll Packages)
Später hatte ich das dann, im FinalBuilder+VBScript und nun im Delphi, für alle 240 Packages übernommen.



Prinzipiell könnte man die Funktion auch für alle möglichen anderen Fremdkomponenten bereitstellen.
PackageListe reingeben, Ein-/Ausgabepfade, eventuelle Suchpfade und angepasste Optionen für den Compiler
und dann wird aus den Packages alles restliche automatisch ausgelesen.
-> im Prinzip gingen auch gleich ALLE fremdkomponenten und der eigenen Code -> da ALLE Packages suchen, sortieren und in der richtigen Reihenfolge kompilieren.

Machen wir aber aktuell manuell im FinalBuilder und da dann auch teilweise Multithread, weil Packages/FremdKomponenten, ohne Abhängigkeiten untereiander, können auch parallel kompilieren.
-> Im FinalBuilder hatte ich beim DevExpress-Kompilieren das 32 und 64 Bit parallel -> in der EXE aber aktuell sequentiell, was etwas länger braucht (wenn für MultiThread genug RAM und schnelle SSD verfügbar)

Zitat:

Wir zahlen jedenfalls jedes Jahr ein haufen Geld. ...um dann den Rechner runiert zu bekommen.

Um an den Quellcode zu kommen, muß es installiert werden (es ist anstrengend das Setup manuell zu entpacken ... andere Hersteller haben einen Parameter für das Setup, für sowas)
das mache ich jetzt nur noch auf meinem lokalen PC (den kann ich notfalls schnell aus dem mehrmals täglichen Backup zurücksetzen) ... auf dem TerminalServer zerhaut es Einem alles.

Noch schlimmer, wenn man beim Installieren "für alle" anhackt, dann wird
nach HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Embarcadero\BDS\22.0\Known Packages
anstatt HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Known Packages
registriert und das wird vom Delphi bei jedem Nutzer reingezogen,
aber beim Lagen nimmt Delphi nicht "immer" die registrierten Pfade, sondern wenn ein Package ein Anderes lädt, dann über die Suchpfade,
und es ist echt grauenhaft, wenn unterschiedliche Versionen gemischt aus verschiedenen Verzeichnissen geladen werden.

Unser FinalBuilder hat daher inzwischen eine Prüffunktion, um die registrierten Pfade zu checken (ob nichts in HKEY_LOCAL_MACHINE steht)
und ansonsten die BPLs aus "unserem" Entwicklungsverzeichnis zu laden. (die Registrierungen bei Bedarf neu "richtig" eintragen zu lassen)

Zitat:

Das ist zumindest ein Anfang, dann kann man eine existierende Installation auch mal auf einem anderen Rechner übersetzen. Sweet!

Jupp, wir haben alles in mehreren GitRepos.
Der FinalBuilder baut alles neu.
Und der FB stellt auch bissl was im Delphi ein. (registrierte Packages und ein paar Grundeinstellungen, die wir in der Firma als Standard festgelegt haben, bzw. welche Standardmäßig im Delphi einfach nur nervig/grauenhaft sind)

Einiges hab ich aber vor Kurzem in ein paar Batch ausgelagert (eigenes Repo), vor allem die Zuatztools, welche mit dem Programmcode/Kompilierung nicht direkt zu tun haben (bissl sauberer getrennt und nicht Jeder will immer alles)
-> bissl was aus dem GetIt (Parnassus), GExperts, DocumentationInsight usw.

Neuer Mitarbeiter, neuer Rechner, neues Delphi, sonstwas (Meistens also schon der letzte Punkt)
> Setups vom FTP runterladen (Delphi und eventuell Hilfe- oder Setup-Compiler)
> Delphi installieren
> die paar Batches ausführen -> Parnassus, GExperts, DocumentationInsight usw. installieren, sowie allgemeine Grundeinstellungen im Delphi
> GitRepos laden und darin den FinalBuilder starten -> die "Einrichten"-Checkbox anhaken -> fertig







Wir haben aktuell ein mehrere GB großes Repo im GitHub, weil über Jahre die ganzen Binarys mit eingecheckt wurden (fing damals schon im SVN an, welches dann nach Git migriert wurde)
Nur noch mit den Sourcen, Demos, Hilfedateien, Dokumentation usw. und wenn man die alten Revisionen bereinigt, sind es vielleicht nur noch 300 MB.

Alle Repos zusammen (GitDir + Checkout), inkl. der aktuellen Kompilate (BPL/DCU/...) und den gebauten Setups aus 2 Delphiversionen, ist das Verzeichnis hier grade fast 25 GB klein.
Vor allem die Binaries der Fremdkomponenten-Packages für Linux/Android ... also da ist DevExpress und Co. echt vollfett. (und die sind im Checkout garnicht mehr drin, aber)
.git\objects der ExternenKomponenten ist aktuell fast 6 GB. (nach einem echt langen Repack, was den RAM sprengt, wenn man bei 63 Kernen das Git nicht begrenzt)

Einige Arbeiten auf dem TerminalServer ... mehrere 15-25 GB Verzeichnisse hauen ein kleines SSD-RAID schnell zu.
Zum Glück läuft nun ab und an ein Service, der gleiche Blöcke auf der Platte zusammenfasst.


Wir haben von allen FremdKomponenten ja die QuellCodes im Git. Da ist es nicht unbedingt nötig die Binaries mit zu versionieren ... auch so kann man jederzeit zurück und eine alte Version so neu zusammenbauen, wie sie bei einem Kunden grade läuft.
Ich lasse vom FinalBuilder die Versionsinfos aller beteiligten Repos zusammenstellen und als Ressource in alle Binaries, im InfoDialog der App und in die PE-VersionsInfo (hier zumindestens das HauptRepo) einfügen.
* BranchName+Datum+Hash

Nur (vorwiegend) DevExpress kam kommt noch in vorkompilierter Version ins Repo. (kommt, weil mein Selbstkompilieren ist noch nicht im Master)




Ein Kollege hatte paar mal intensiv mit DevExpress zu kämpfen und da ist es nervig ihm erstmal ein DevExpress mit DebugInfos zu besorgen/bauen,
weil im Repo liegen ja nur die Release-Versionen der Packages (abgesehn von ein paar wenigen Dabug-Dateien für das DevExpressGrid im TestComplete)

Jetzt kann ich im FinalBuilder über eine Checkbox sagen "mit oder ohne Debuginfos",
wobei ich gerade anfange alles immer mit "externen" Debuginfox (TDS daneben, nicht in der EXE/DLL/BPL) zu kompilieren und Diese bei den Fremdkomponenten in eine ZIP packen zu lassen. (kann man auspacken, wenn benötigt)


Sowas baut mir das FinalBuilder-Script

Code:

1 VERSIONINFO
  FILEVERSION 23,11,00,00
  PRODUCTVERSION 23,11,00,00
...
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904E4"
        BEGIN
            ...
            VALUE "ProductVersion", "23.11.00.00\0"
            VALUE "FileVersion", "23.11.00.00\0"
            ...
            VALUE "Comments", "23.04.07.01+15 317e7264a*\0"
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x0409, 1252
    END
END

oder

Delphi-Quellcode:

const
  xxxxxxVersion        = '23.11.00.00';
  xxxxxxGitBranch      = 'master*';
  xxxxxxGitVersion     = '23.04.07.01+15 317e7264a*';
  xxxxxxGitLongVersion =
    'XXXXXX:  master* 23.04.07.01+15 317e7264a*'#10 +
    'EXTERN:   dev/fs/18948-d11-und-setup 23.04.07.01+36 1ef09d97c*'#10 +
    'ROOT:       dev/fs/18948-d11-und-setup 23.04.07.01+46 d97dcaf85*'#10 +
    'PSQL:        master 23.04.07.01+9 79d6d36e'#10 +
    'COMPILE: xxxMEINNAMExxx @ xxxCOMPUTERNAMExxx';

Die * sind, weil ich hier grade nichtcomittete Änderungen im Verzeichnis hab.
Das Setup wird ja normal aus einmen sauberen aktuellem Release-Branch erstellt.

Und diese Info landet inzwischen auch in den Details der FehlerDialoge,
damit man endlich weiß mit was man es zu tun hat.

[Stevie]

TL'DR

DevExpress Setup einfach lokal ausführen, dann den Source ins git packen und mit DelphiPI kompilieren lassen - machen wir schon seit Jahren so.

[himitsu]

Zitat:

DelphiPI automatically resolves dependencies between packages, compiles, installs and adds source paths to your IDE.

Also im Grunde mach ich auch nichts Anderes.
Nur die masse an Source-Paths registriere ich nicht mehr ... damit hatte ich schon gen Start der gesamten IDE lahmgelegt, weil sie mit dem zu langen Suchpfad nicht klar kam, selbst als ich das meiste in eine via %DXVCL%-Variable gekürzt hatte.
Delphi brach ohne Fehlermeldung einfach so mittem in Starten ab und beendete sich wortlos.

Gut, mein hässlicher Code ist noch mehr auf DevExpress ausgelegt, aber wie schon gesagt

Zitat:

Prinzipiell könnte man die Funktion auch für alle möglichen anderen Fremdkomponenten bereitstellen.

und es gibt keine GUI

Zitat:

This repository has been archived by the owner on Jul 31, 2019. It is now read-only.

Wenn ich mal rausfinde, wie man den LLVM anspricht, damit er mir die Dateien parst,
wäre es bestimmt möglich die DX-Sonderheiten in eine Config auszulagern und mal zu schauen, was man von dem anderen Projekt übernehmen könnte.

Mein manuelles "Parsen" bezieht sich darauf, dass der Teil im DevExpress nicht schlimm aussieht und es "einfach" ging,
aber für mir unbekannte Komponenten wäre es zu fehleranfällig.

[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)