Open Sourcing von Komponenten - Best Practices?

[Nersgatt]

Package oder nicht, hat Vor- und Nachteile.

Wenn Du Units hast, die eigenständig funktionieren, dann finde ich es besser, diese Unit einfach einzeln rauszugeben. Die füge ich dann meinem Projekt hinzu und fertig.
Wenn Du aber Abhängigkeiten zwischen mehreren (vielen) Units hast, dann finde ich es besser, die zu einem Package zusammen zu fassen.

[Der schöne Günther]

Klassen würde ich keine Pre- und Postfixe andichten wollen. Eigentlich wäre dazu der Namensraum da. Da Delphi als billigen Ersatz immerhin Punkte in Unitnamen zulässt könnte man ja immerhin die Benennung der Units reglementieren: CrazyLib.FluxCapacitor.pas mit einem TFluxCapacitor drinnen.

Ein schönes Beispiel dafür finde ich die (leider recht unbekannte) Lib von Cromis.net:
https://www.cromis.net/svn/cromis/lib/pas/CromisCode

[Insider2004]

Packages nur bei visuellen Komponenten in der K-Leiste. Alles andere ist Käse. Da gibt's Leute die machen aus jeder Prozedur eine Komponente.

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

[himitsu]

Zitat von Der schöne Günther:

Klassen würde ich keine Pre- und Postfixe andichten wollen.

Es kommt drauf an.

Ein supergutes Edit sollte man aber nicht TEdit nennen, denn in der VCL IDE gibt es keine Namensräume.
(OK, gibt es, aber nicht im FormDesigner ... Beispiel )

[Der schöne Günther]

Klar, an grafische Komponenten habe ich jetzt überhaupt nicht gedacht...