Open Sourcing von Komponenten - Best Practices?

[jaenicke]

Zitat von Insider2004:

Packages nur bei visuellen Komponenten in der K-Leiste. Alles andere ist Käse.

Sehe ich anders. Wir haben unsere Units in Packages gesteckt und kompilieren diese mit definierten Ausgabeverzeichnissen für die jeweiligen Plattformen. Der Bibliothekspfad ist entsprechend nur auf ein einziges Ausgabeverzeichnis (mit Platzhaltern für die Plattform) gesetzt. Die Suchpfade führen zu allen Quelltextunits.

Kompiliert wird das ganze per Batchdatei.

Auf diese Weise hat man die Quelltexte sauber von den kompilierten Units getrennt. Und die Units werden auch nicht dauernd unnötig neu kompiliert...

[Sir Rufo]

Der Vorteil von einem Package für eine Bibliothek ist die gesparte Zeit beim Kompilieren, da die Units ja schon kompiliert vorliegen.

Aufpassen muss man nur, dass man nicht den Debug-Code in die Anwendung bekommt. Darum erzeuge ich die DCU-Dateien immer im Verzeichnis "lib\DELPHI-VERSION\$(Platform)\$(Config)" und erzeuge die Dateien für alle Plattformen jeweils als Release und Debug.

Als Bibliotheks-Pfad dann "lib\DELPHI-VERSION\$(Platform)\Release" und bei Debug-DCU-Pfad "lib\DELPHI-VERSION\$(Platform)\Debug".

Die Suchpfade wie gehabt und der Drops ist gelutscht.

[jaenicke]

Ja, genau so. Und in Jenkins, das wir als Buildsystem nutzen, passiert das auch entsprechend automatisiert.

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

[mquadrat]

Lässt sich das mit der Delphi-Version auch irgendwie automatisieren?

Im Szenario wäre es ja so, dass wir logischerweise nur die Variante für die Delphi Version, die wir verwenden (aktuell XE2) zur Verfügung stellen. Wir würden also das Projekt zur Verfügung stellen und jeder möge es sich dann selber compilieren. Oder anders formuliert: Ich hätte gern nur eine Projektdatei

[NicoDE]

Zitat von jaenicke:

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

Wäre es dann nicht einfacher das Package-Projekt in die Projektgruppe aufzunehmen und Abhängigkeiten zu definieren?

[jaenicke]

Zitat von mquadrat:

Ich hätte gern nur eine Projektdatei

Solange die Projektdatei mit anderen Delphiversionen auch funktioniert, sprich die gleichen Units und Einstellungen nutzt, funktioniert das.
Allerdings ist das Ausgabeverzeichnis dann für alle gleich. Das wiederum ist schlecht für Parallelinstallationen. Ich weiß nicht, ob es auch dafür einen Platzhalter gibt, bei uns sind ohnehin eigene Packages pro Version notwendig.

Es sollte für potentielle Nutzer aber kein Problem sein das selbst anzupassen, sprich eigene Packages entsprechend zu erstellen.

Zitat von NicoDE:

Zitat von jaenicke:

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

Wäre es dann nicht einfacher das Package-Projekt in die Projektgruppe aufzunehmen und Abhängigkeiten zu definieren?

Einzeln lässt sich das Komponentenprojekt auch schlecht kompilieren, da daran Buildskripte usw. hängen. Diese schieben die kompilierten Units hin- und her, so dass nicht nur die eine Unit kompiliert wird, sondern einiges mehr, so dass das Kompilieren nicht so schnell geht.