PAS-Dateien im Suchpfad nicht neu kompilieren wenn nicht nötig

[Der schöne Günther]

Es gibt so viele tolle Bibliotheken da draußen. Man "installiert" sie und kann fortan bunte Vierecke auf seine Formulare ziehen. Noch wichtiger: Man hat die Sourcen einmal kompiliert, nun DCUs im Bibliothekspfad liegen und braucht sie nicht jedes mal kompilieren.

Alles gut soweit.

Nun gibt es Leute die haben keine Lust nach jedem RAD Studio-Release auf X Geräten Komponenten zu ziehen und zu installieren. Ich möchte die Quelltexte der Libraries nun an die Projekte selbst mit dranhängen.

Das klappt auch: Man legt die Bibliothek z.B. als Sub-Repository des Projekts an, stellt in den Projekt-Optionen noch als Suchpfad z.B.

Code:

.\..\libs\Graphics32

und fertig. Man muss halt jetzt darauf verzichten im Formular-Designer die Dinge aufs Formular zu ziehen aber das stört nicht. Weiterer Bonus: Verschiedene Projekte können mit verschiedenen Versionen von Libraries arbeiten und man kann sie sehr einfach auswechseln (Subrepo updaten)

Das Problem: Ich gehöre zu den Leuten die nichts gegen Komponenten-Installationen haben. Ich möchte nicht jedes mal die Sourcen neu kompilieren, denn die DCUs habe ich ja in meinem Bibliothekspfad liegen. Was kann ich tun?

Folgende Ideen hatte ich bislang:

• Subrepo für mich lokal auf "leer" stellen: Somit werden im Suchpfad keine PAS-Dateien gefunden und er nimmt die DCUs aus dem Bibliothekspfad
• Neben Debug und Release eine weitere Gruppe "Debug_NoLocalLibraries" oder so ähnlich, diese hat den Suchpfad dann nicht

[Ghostwalker]

hmm...oder beim Installieren der Componenten den DCU-Pfad auf ein Zentrales Verzeichnis biegen.
(Das ergibt zwar ein "Sumpf" Verzeichnis, aber gut).

Dann nur im Bib-Pfad das Sumpfverzeichnis rein und wie bei Subrepo vorgehen.

Bietet den zusätzlichen Vorteil das auch der Bibleothekspfad entschlackt wird

[Der schöne Günther]

Das Problem ist dass die Leute hier keine Lust mehr auf Komponenten installieren haben und Projekte möglichst "out of the box" laufen sollen.

[Uwe Raabe]

Zitat von Der schöne Günther:

Das Problem ist dass die Leute hier keine Lust mehr auf Komponenten installieren haben und Projekte möglichst "out of the box" laufen sollen.

Das Komponenten installieren kann man aber auch deutlich vereinfachen. Wenn die compilierten Dateien bereits vorliegen, dann genügt ein Doppelklick auf eine entsprechend gefüllte REG-Datei. Es muss sich halt nur einer einmal die Arbeit machen.

[Rollo62]

Ich weiss nicht ob die vorkompilierten DCUs so eine gute Idee sind, schon gar nicht wenn du alte/neue Versionen
benutzen willst.
Da hat sich schnell mal eine alte reingeschlichen, und solche Fehler sind sehr schlecht zu finden,
am ehesten noch durch die verschobenen Debug-Positionen beim testen.
Oder gibt es etwa eine sichere Methode mit der man diese alten Leichen verhindern oder zumindest warnen kann ?

Natürlich fände ich soetwas auch super wenn es solche Leichen beim Linken aussortieren könnte.

Ich würde auf jeden Fall einmal im aktuellen Projekt BuildAll vorziehen, und dann sollte alles einmal
aktualisiert sein.
Von da aus wäre natürlich das Kompilieren bei Bedaf sehr sinnvoll wenn es 100% sicher funktioniert,
aber ehrlich gesagt auch da verlasse ich mich selten drauf.

Rollo

[Uwe Raabe]

Zitat von Rollo62:

Ich weiss nicht ob die vorkompilierten DCUs so eine gute Idee sind, schon gar nicht wenn du alte/neue Versionen
benutzen willst.
Da hat sich schnell mal eine alte reingeschlichen, und solche Fehler sind sehr schlecht zu finden,
am ehesten noch durch die verschobenen Debug-Positionen beim testen.

Grunsätzlich bin ich auch auf der "alles aus dem Source compilieren" Seite. Bei den Design-Packages gibt es aber einen durchaus relevanten Aspekt für die globalen DCU-Suchpfade: in der Regel entsprechen die DCUs dann nämlich auch den zur Designzeit verwendeten Komponenten.

Dies ist auch einer der Gründe, weswegen ich meinen Package Magician geschrieben habe. Damit kann man die für ein Projekt benötigten Design-Packages dynamisch mit dem Projekt laden. In dem Fall sind dann die projektbezogenen Suchpfade auf die Bibliotheken wieder sinnvoll.

[Der schöne Günther]

Dadurch dauert aber, insbesondere bei großen Bibliotheken, das Kompilieren relativ lange. Theoretisch sollte man das nur einmal müssen, aber das RAD Studio kommt leider immer durcheinander wenn sich durch das Versionierungstool viel ändert (z.B. Zweig wechseln/Patches runternehmen) sodass man gezwungen ist, einmal auf "Bereinigen" zu drücken.

Ich vorkompilierte DCUs schon sinnvoll dafür.

[mm1256]

Zitat von Der schöne Günther:

Dadurch dauert aber, insbesondere bei großen Bibliotheken, das Kompilieren relativ lange...

Nun ja, kommt darauf an, was du unter "relativ" verstehst. Mit dem Einsatz entsprechender Hardware lässt sich viel "relativieren". Wenn ich als Beispiel mein größtes Projekt mit ca. 570 eigenen Units und zahlreichen Bibliotheken komplett neu compiliere, und das ca. 10 Sekunden dauert, dann denke ich, ist das Potential das man durch vorkompilierte DCU's noch ausschöpfen kann "relativ" gering. Vielleicht im Bereich von geschätzt 2-3 Sekunden. Da braucht es schon ca. 20 Re-Builds um gerade mal eine Minute einsparen zu können.

Wenn ich aber stattdessen das selbe Projekt auf meinem Notebook compiliere... Ich denke, sich über die Hardware Gedanken zu machen, bringt mehr

[galex9]

Zitat von Uwe Raabe:

Dies ist auch einer der Gründe, weswegen ich meinen Package Magician geschrieben habe. Damit kann man die für ein Projekt benötigten Design-Packages dynamisch mit dem Projekt laden. In dem Fall sind dann die projektbezogenen Suchpfade auf die Bibliotheken wieder sinnvoll.

Hallo Uwe, kannst du etwas mehr darüber erzählen?

Sonst war bei mir Lazy Delphi Builder im Einsatz

[Uwe Raabe]

Zitat von galex9:

Hallo Uwe, kannst du etwas mehr darüber erzählen?

Klar! Ich denke, jeder ist schon mal in der Situation gewesen, daß er mit unterschiedlichen Versionen einer Bibliothek arbeiten musste. In dem Fall bieten die verschiedenen Versionsverwaltionssysteme die nötigen Mittel, um die richtigen Versionen der verschiedenen Bibliotheken einzubinden (bei SVN z.B. die Externals). Das Problem dabei ist aber, daß die IDE in der Regel davon unbeeinflusst bleibt und lediglich das Design-Package geladen hat, was als letztes installiert wurde (vermutlich die letzte Version der Bibliothek). Das kann nun dazu führen, daß zur Designzeit die Version der BPL nicht zur Version der Sourcen passt die compiliert werden. Im ungünstigen Fall werden dabei neue Properties in die DFM geschrieben die zur Laufzeit nicht bekannt sind.

Ein weiterer Fall aus der Praxis: Ein bestehendes Projekt verwendet projektspezifische Komponenten aus einem Design-Package zu diesem Projekt, das in der IDE installiert werden muss. Andernfalls werden diese Komponenten auf den Forms nicht gefunden. Nun wird dieses Projekt von der BDE zu FireDAC migriert. Die in den Komponenten verwendeten TQuery-Typen werden dabei durch TFDQuery ersetzt. Die requires-clause des Package wird folglich von BDE- auf FireDAC-Packages umgestellt. Jetzt existieren zwei gleichnamige Packages mit fast identischem Inhalt (eines gegen die BDE compiliert und eines gegen FireDAC), die natürlich nicht gleichzeitig in die IDE installiert werden können. Will ich nun wechselweise die BDE-Version und die FireDAC-Version des Projekts bearbeiten, muss ich jedesmal erst das aktuelle Projekt schließen, das Package deinstallieren, das andere Package installieren und das andere Projekt öffnen.

Hier bietet der Package Magician eine transparente Möglichkeit, Design-Packages projektbezogen zu installieren. Dabei werden diese projektbezogenen Packages mit dem Öffnen des Projekts in der IDE installiert und beim Schließen des Projekts wieder deinstalliert. Man kann nun einfach wieder die Projekte umschalten und hat automatisch immer das passende Design-Package geladen.

Man kann mit dem Package Magician auch die Komponenten-Inflation etwas eindämmen. Die Komponentensammler unter uns kennen die überquellenden Komponentenpalette und die überlangen Ergebnislisten, wenn man z.B. bei F6 "label" eingibt. In den jeweiligen Projekten werden aber in der Regel nur ein Teil dieser Bibliotheken wirklich verwendet. Mit dem Package Magician kann man nun alle diese Design-Packages aus der IDE entfernen und nur bei den Projekten laden, in denen sie tatsächlich gebraucht werden (dann auch in der passenden Version - siehe oben).

Zitat von galex9:

Sonst war bei mir Lazy Delphi Builder im Einsatz

Ich kenne das Tool nicht und kann auch so auf den ersten Blick nicht erkennen, ob es bei den oben beschriebenen Szenarien eine Hilfe ist.