Packages: Best Practices, Tipps und Tricks

[s.h.a.r.k]

Hallo zusammen,

bin gerade dabei meine eigene Komponentensammlung zusammenzubasteln und diese in Packages zu packen. Nun hab ich schon ein paar Dinge über Packages gefunden, was mir so noch nicht wirklich bewusst war. Daher suche ich im Moment gute Artikel über das Thema, kleine "Geheimnisse", Tipps, Tricks, Best Practices etc.

Nur was stelle ich mir nun aber darunter vor? Ich weiß z.B. im Moment noch nicht so recht, welche Ordnerstruktur ich insgesamt einhalten sollte bzw. was dabei eben sinnvoll und zu beachten ist! Wo sind die Fallstricke versteckt? Ebenso die Dateinamen der Packages? Klar kann ich gegebene Komponenten-Packete anschauen, aber sehe daran nicht die Gründe, warum es so ist, wie es ist. Ein Beispiel:

Zitat:

Zitat von http://mc-computing.com/languages/delphi/Packages.html

The DCU's made for one version of Delphi won't work in another version.

Wie macht ihr das immer? Habt ihr eine Anleitung? Eine Art Kurzreferenz?

Hier ein paar Links zum Thema:

• http://delphi.about.com/od/objectpas...bpl_vs_dll.htm
• http://delphi.about.com/od/objectpas.../aa012301a.htm
• http://mc-computing.com/languages/delphi/Packages.html
• http://delphi.wikia.com/wiki/Creating_Packages
• http://www.delphipraxis.net/1064396-post4.html

[chaosben]

Eine Referenz habe ich nicht. Aber dafür einige Jahre Erfahrung (und es waren nicht immer gute :-))

Folgendes ist dabei herausgekommen:

• Kein On-Demand-Build ({$IMPLICITBUILD OFF}) ... das bringt mehr Ärger als Nutzen
• Eine On-Demand-Build-Politik (entweder alle ja oder alle nein)
• Nutzung des Lib-Suffix für den Package-Namen ... dadurch ist es einfacher, das Package unter mehreren Delphi-Versionen zu nutzen
• Wenn man das Libsuffix nicht nutzt, dann das Projekt auf jeden Fall mit Delphi-Version benennen (MeinPackage_D120)
• Die Trennung in Runtime- und Designtime-Package nur wenn es Sinn macht ... also man wirklich Platz spart
• genutzte DLL's dynamisch laden ... sonst muss Delphi die DLL auch laden

Das wars für den Moment ... wenn mir noch was einfällt, sag ichs. :-)

[s.h.a.r.k]

Na, das ist doch schon mal was ;)

Zitat:

Zitat von chaosben (Beitrag 1073493)

• Nutzung des Lib-Suffix für den Package-Namen ... dadurch ist es einfacher, das Package unter mehreren Delphi-Versionen zu nutzen
• Wenn man das Libsuffix nicht nutzt, dann das Projekt auf jeden Fall mit Delphi-Version benennen (MeinPackage_D120)

Was genau verstehst du darunter? Hättest du evtl. ein Beispiel parat, dann wird das wohl alles klarer ;)

[Uwe Raabe]

Wenn du ein Package in der IDE als Projekt offen hast, kannst du in den Projekt-Optionen unter Beschreibung ein LIB-Suffix angeben. Nimm mal an, das Package heißt MyPackage.dpk und das LIB-Suffux ist D15, dann wird beim Compilieren eine MyPackage.dcp und eine MyPackageD15.bpl erzeugt. Der Vorteil ist, daß man beim Required in einem davon abhängigen Package dann nur MyPackage angeben muss. Auch kann die DPR relativ leicht an eine neue Delphi-Version angepasst werden, da lediglich das Suffix geändert werden muss. Da BPLs schon mal gern im Suchpfad liegen, müssen sie für jede Delphi-Version einen anderen Namen haben. Das Suffix bewirkt dies, obwohl das Package selbst seinen Namen behält.

[uligerhardt]

Zitat:

Zitat von Uwe Raabe (Beitrag 1073745)

Wenn du ein Package in der IDE als Projekt offen hast, kannst du in den Projekt-Optionen unter Beschreibung ein LIB-Suffix angeben. Nimm mal an, das Package heißt MyPackage.dpk und das LIB-Suffux ist D15, dann wird beim Compilieren eine MyPackage.dcp und eine MyPackageD15.bpl erzeugt. Der Vorteil ist, daß man beim Required in einem davon abhängigen Package dann nur MyPackage angeben muss. Auch kann die DPR relativ leicht an eine neue Delphi-Version angepasst werden, da lediglich das Suffix geändert werden muss. Da BPLs schon mal gern im Suchpfad liegen, müssen sie für jede Delphi-Version einen anderen Namen haben. Das Suffix bewirkt dies, obwohl das Package selbst seinen Namen behält.

Ich hab mal versucht, das für ein paar meiner Packages durchzuziehen. Eines davon hat aber ein Third-Party-Package required, das diese LIB-Suffix-Funktionalität nicht nutzt. Also hätte ich je nach Ziel-IDE mal My3rdPartyCompsD11, mal My3rdPartyCompsD12, ... requiren müssen, was ich nicht hingekriegt habe. Wie würdet ihr in so einem Fall vorgehen - ein eigenes Package (mit LIB-Suffix) für die Fremdkomponenten anlegen? Oder gibt's einen Trick, dass es auch mit den Originalpackages klappt?

[Uwe Raabe]

Zitat:

Zitat von uligerhardt (Beitrag 1073749)

Ich hab mal versucht, das für ein paar meiner Packages durchzuziehen. Eines davon hat aber ein Third-Party-Package required, das diese LIB-Suffix-Funktionalität nicht nutzt. Also hätte ich je nach Ziel-IDE mal My3rdPartyCompsD11, mal My3rdPartyCompsD12, ... requiren müssen, was ich nicht hingekriegt habe. Wie würdet ihr in so einem Fall vorgehen - ein eigenes Package (mit LIB-Suffix) für die Fremdkomponenten anlegen? Oder gibt's einen Trick, dass es auch mit den Originalpackages klappt?

Du kannst ein Dummy-Package anlegen, daß das FremdPackage required. Da implizit verwendete Packages nicht angegeben werden müssen, reduziert sich der Änderungsaufwand auf dieses Dummy-Package.

Wenn nicht klar ist, was mit "implizit verwendet" gemeint ist: Benötigt ein Package z.B. RTL und VCL so genügt es lediglich VCL anzugeben, da dieses bereits RTL "implizit verwendet".

[uligerhardt]

Zitat:

Zitat von Uwe Raabe (Beitrag 1073766)

Du kannst ein Dummy-Package anlegen, daß das FremdPackage required. Da implizit verwendete Packages nicht angegeben werden müssen, reduziert sich der Änderungsaufwand auf dieses Dummy-Package.

Danke, probiere ich bei Gelegenheit.

Und wie gibst du das LIB-Suffix konkret an? Ich habe es damals so probiert, wie es Ray Konopka hier beschrieben hat, obwohl das nicht 1:1 geklappt hat - es gab bei mir ähnliche Probleme wie sie Lucian beschreibt, die ich allerdings WIMRE mit einer weiteren Indirektion umgehen konnte.

[Uwe Raabe]

Zitat:

Zitat von uligerhardt (Beitrag 1073768)

Und wie gibst du das LIB-Suffix konkret an? Ich habe es damals so probiert, wie es Ray Konopka hier beschrieben hat, obwohl das nicht 1:1 geklappt hat - es gab bei mir ähnliche Probleme wie sie Lucian beschreibt, die ich allerdings WIMRE mit einer weiteren Indirektion umgehen konnte.

Ray benutzt $IFDEFs in der DPR-Datei und hat damit nach eigenen Angaben auch Probleme in der IDE. Mit seinem Build-Batch geht es zwar, man sollte die Packages aber tunlichst nicht in der IDE öffnen.

Ich gebe das LibSuffix in den Projekt-Optionen an, verwende aber eigene Verzeichnisse mit den Projekt-Dateien für die einzelnen Delphi-Versionen. Das ist sowieso kaum zu vermeiden, da z.B. die dproj-Dateien nicht abwärtskompatibel sind. Kommt nun eine neue Delphi-Version heraus, kopiere ich das Verzeichnis der letzten auf das neue, lade die Packages und ändere lediglich das Suffix und eventuell noch den DCU-Pfad. BPL- und DCP-Pfad sind eh auf die Standardwerte gesetzt und sind somit Delphi-Versions-neutral. Ein bißchen blöd ist es, wenn neue Units dazu kommen, da die in allen Delphi-Versionen nachgepflegt werden müssen. Allerdings verwende ich aktiv nicht so viele Versionen und es kommen auch nicht so häufig neue Units dazu.

Eigentlich bräuchte es eine interne Variable für das Suffix, daß vom Compiler gesetzt wird. Aternativ wäre das auch über ein OptionSet denkbar. Gibt's aber alles noch nicht.

[DSCHUCH]

Dem stimme ich mehr als zu. Eine Erfahrung von uns: nicht versuchen mit Delphi zu compilieren wenn man viele aufeinander aufbauende packages gleichzeitig in der IDE nutzt. extern compilieren, wir löschen vor dem compieren grundsätzlich alle binaries (dcu, dcp, bpl) da man nie im überblick hat wenn units versehentlich falsch eingebunden sind und dann fehlerhafte dcu eingebunden werden.
compilerdirektiven in dpk's zur abgrenzung unterschiedlicher delphi versionen funktionieren nicht (wie bereits jem. anmerkte)

Zitat:

Zitat von chaosben (Beitrag 1073493)

Eine Referenz habe ich nicht. Aber dafür einige Jahre Erfahrung (und es waren nicht immer gute :-))

Folgendes ist dabei herausgekommen:

• Kein On-Demand-Build ({$IMPLICITBUILD OFF}) ... das bringt mehr Ärger als Nutzen
• Eine On-Demand-Build-Politik (entweder alle ja oder alle nein)
• Nutzung des Lib-Suffix für den Package-Namen ... dadurch ist es einfacher, das Package unter mehreren Delphi-Versionen zu nutzen
• Wenn man das Libsuffix nicht nutzt, dann das Projekt auf jeden Fall mit Delphi-Version benennen (MeinPackage_D120)
• Die Trennung in Runtime- und Designtime-Package nur wenn es Sinn macht ... also man wirklich Platz spart
• genutzte DLL's dynamisch laden ... sonst muss Delphi die DLL auch laden

[chaosben]

Ja, der Uwe hat das genau richtig erklärt.
Vielleicht noch ein Nachsatz:
Der Umgang Delphis mit BPL's und DCP's ist gut. Daran sollte man (so man nicht der absolute Freak ist) nichts ändern. Also keinen anderen BPL-Pfad oder DCP-Pfad setzen. Einfach an das halten was Delphi von selbst macht ... da hat man die wenigsten Probleme.

Das gilt natürlich nur, wenn es um Delphi-Komponenten geht. Baut man ein eigenes Projekt auf BPL's auf, sollte man sehr wohl diese Pfade selbst definieren.

Btw.: das Lib-Suffix kannst du natürlich auch gern per Compiler-Define in der Projekt-Datei bestimmen. :)