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.