Dürfen Packages für D und BCB gleiche Namen haben?

[messie]

Moin,

ich habe gerade große Probleme beim Installieren von Packages mit dem BCB. Beim Bereinigen für den nächsten Versuch ist mir aufgefallen, dass die Packages gemeinsam verwaltet werden. Wenn ich jetzt ein BCB-Package kompiliere, wird dann nicht eine andere bpl erstellt? Denn die Abhängigkeiten sind ja unterschiedlich, insbesondere bei den Packages, wo ich BCB/Delphi-spezifische Abhängigkeiten habe (TMS Unicode, Alphaskins).

Gibt es da Vorgaben und Regeln? Denn in D6/BCB6 hatte ich ja weitgehend getrennte Pfade.

Grüße, Messie

[messie]

Moin,

ich muss das nochmal pushen. Ich hatte bisher bei D6/BCB6 jeweils ein Package gleichen Namens und gleicher Funktion, weil die ja unterschiedlich abgelegt waren. Es gab aber unterschiedliche Abhängigkeiten, je nach Compiler. Muss ich jetzt eigene Packages für Delphi und BCB machen oder kann ich alles in ein Package tun? Wenn ja, wie?

Danke, Messie

[Muetze1]

Wenn du nun ein BDS2006 oder späteres Produkt nutzt, dann brauchst du nur ein Package. Aber nun zu Details:

1. nur Delphi Komponenten für Delphi & C++Builder

Umgebung: BDS/RAD Studio (keine einzelne Personality!)
Packages: C++Builder Packages anlegen (nicht die Delphi Packages!)

Wenn es nur Delphi Komponenten sind, dann diese in ein Packagesystem einbinden (DTL und RTL) und bei den Optionen einstellen, daß die *.bpi, *.lib und *.hpp mit erzeugt werden. Dann das DTL Package einfach registrieren (die Laage muss wie auch die RTL Packages im Suchpfad liegen, damit die IDE diese laden kann) und fertig.

Bei C++ Projekten dann wenn die Komponenten verwendet werden entweder die *.LIB direkt vom Explorer in den Projektmanager ziehen. Danach entfernen wir die Pfadangaben in dem Projektfile und setzen den LIB Suchpfad des Projektes zusätzlich zu dem Ort mit der .LIB Datei des Packages (RTL).

2. nur C++ Komponenten für C++Builder

Umgebung: BDS/RAD Studio oder C++Builder Personality
Packages: Delphi Packages anlegen

Da die C++ Komponenten nicht unter Delphi verwendet werden können ist hier die Vorgehensweise die allgemein übliche. Einfach beide C++Packages erzeugen, installieren und gut ist. Hinweis zum Suchpfad wie zuvor gilt hier auch für die BPL

3. nur Delphi Komponenten für Delphi

Umgebung: BDS/RAD Studio oder Delphi Personality
Packages: Delphi Packages anlegen

Auch hier alles wie gehabt, gleiches zu den Suchpfaden.

4. Allgemeines

Suchpfad sollte möglichst vorher entsprechend erweitert werden, wenn man nicht den von CodeGear vorgeschlagenen BPL Pfad verwenden will. Unbedingt bei allen Packages Aktionen darauf achten, dass die IDE nicht irgendwelche Pfade in den IDE weiten Library Suchpfad einträgt. Diesen schwachsinnigen Code haben sie in der aktuellen IDE immernoch so drin.

Namen von Packages dürfen nicht doppelt vergeben werden. Von daher auch die RTL und DTL Packages kennzeichnen. Unterschiedliche Versionen von Delphi/C++Builder haben auch unterschiedliche Compileroptionen, also lieber auch noch für die jeweilige Version ein Packages anlegen.

Die Beschreibungen der Packages dürfen nicht mit einem _ anfangen, ansonsten werden sie von der IDE nicht angezeigt. Das ist ein weiterer Schwachmatismus von CodeGear.

Wenn Delphi Quellen (z.B. Komponenten) unter dem C++Builder genutzt werden oder anderweitig Code gemischt wird, muss man explizit in den Delphi Units welche die Enum Größe festlegt einen entsprechenden Compilerschalter einfügen, damit diese gleich groß sind. Der Delphi Compiler macht diese immer nur so groß wie er sie zur Darstellung aller Elemente benötigt (d.h. in den meisten Fällen ein Byte). Die entsprechende Delphi Compiler Option in den Projektoptionen wird in solchen C++Builder Packages beim Delphi Compiler Aufruf nicht weitergereicht. D.h. die Einstellung ist komplett wirkungslos (von BDS2006 (keine Option in der IDE) bis RAD2007 (Option vorhanden, nicht weitergereicht) als Bug vorhanden; RAD2009 ungetestet) und führt dadurch beim Memberzugriff von C++ zum überschreiben von anderen Daten.

Der Datentyp Comp, UInt64 sowie Nutzung die von virtuellen abstrakten statischen Methoden sind nicht C++Builder kompatibel. Erstere beide klappen dank des HPP Generators nicht (bis mindestens einschliesslich RAD2007) und letzteres bietet der C++ Sprachumfang nicht an. Letzteres ist durch eine virtuelle statische Methode ersetzbar, welche eine EAbstractError Exception wirft. UInt64 wird durch den HPP Generator immer als Int64 übersetzt was dann beim linken eine unresolved external reference bringt, da der Linker nur eine Methode mit UInt64 Signatur findet.

Konstanten innerhalb von Klassen bekommen z.T. andere Datentypen oder auch Werte durch den HPP Generator/C++Builder Linker und Typdeklarationen (Enumerations, Klassen, etc) sind auch nicht nutzbar, da entweder der HPP Generator daraus Müll macht oder C++ keine Entsprechung dazu bietet.

Wenn man vom C++Builder bzw. einer C++ Anwendung in eine Delphi Klasse debuggen will so klappt dies nur wenn die Flags "DebugInLib" bzw. "DebugInEXE" in den Projektfiles eingetragen sind und aktiviert sind. Beim BDS2006 gab es zu diesen Optionen bisher keinen entsprechenden Schalter in der IDE und die Optionen wurden standardmäßig nicht eingefügt oder aktiviert. Wenn man aber ein altes Package aktualisiert hatte, wurde die Option eingetragen. Ab RAD2007 gibt es dazu eine Entsprechung in der IDE bei den Optionen, aber das Flag wird trotzdem meist nicht richtig gesetzt und z.T. durch reines Öffnen einer LIB bzw. eines Packages wieder zurück gesetzt oder einfach ganz entfernt. Ohne dieses Flag erhält man keine Codepunkte in den Pascal Quellen und somit keine Debugging Möglichkeit. Auch Symbole und Variablen sind nicht verfügbar. Beim Debuggen mit dem C++Builder in Delphi Quellen immer beachten, dass Evaluierungen immer nach C(++) Standard erfolgen. Also this und nicht Self und * anstatt ^, etc.

Das sind nur mal ein paar kleine Dinge dazu. Ich hoffe damit kannst du deine Packages integrieren. Weitere Fehler und Unzulänglichkeiten (zumindest bis RAD2007 verfolgt) findet man auch hier.

[messie]

Hmmm, habe versucht, das so umzusetzen. Die Packages der TMS Tools lassen sich zumindest getrennt installieren und machen erstmal keinen Ärger. Vielleicht kommt der später.
Bei den eigenen Komponenten habe ich die Packages in BCB erzeugt und installiert und in Delphi die bpls nachgeladen, das scheint erstmal bei einigen zu klappen. Nicht aber bei den Alphaskins. Auch da gibt es getrennte Packages, die aber auf eine gegenseitige Abhängigkeit bestehen (siehe Anhang). Und da gibt es dann Ärger, weil angeblich das Builder-Package nicht gefunden wird. Die Suchpfade scheinen nicht benutzt zu werden.

Alle Komponenten sind im Ursprung Delphi-Komponenten.

Grüße, Messie

[Muetze1]

Hallo!

Ich habe explizit nochmal nachgeschaut und muss mich korrigieren: In dem Punkt von Delphi Komponenten für C++Builder und Delphi sind es doch Delphi Packages. Mein Fehler.

Zu deinem Screenshot: Dein Package acnt2009_R (ich vermute RTL) hat Referenzen auf die aufgezählten Units. Um diesen Knoten aufzulösen einfach über die IDE das acntBCB2009_R Package in den Require Block einfügen lassen (also dort dann nur acntBCB2009_R angeben, beim acnt2009_D natürlich dann das acntBCB2009_D angeben).

Aber grundlegend ist diese Meldung mit Vorsicht zu genießen, sehr oft kommt die IDE mit dieser Meldung hoch, ohne das die von ihr propagandierte Änderung nötig ist. Hier kann man sich leicht die Packages mit zerschiessen. Wenn also irgendeine Unit(s) aus acnt2009_R wirklich eine Unit benötigt welche schon im Package acntBCB2009_R enthalten ist (implizit oder explizit), dann brech den Dialog ab und trage im Required Block dein Package ein.

[messie]

So, ich habe es jetzt hinbekommen.

Dabei ergibt sich in etwa folgendes (genähertes) Regelwerk:

1. Wenn gelieferte Packages für Delphi und BCB vorhanden sind, die Packages für Delphi vorrangig verwenden.

2. Bei gelieferten Delphi-Packages: Möglichst das dproj-Package öffnen und in den Linkeroptionen das Erstellen von BCB-Packagedateien wählen (siehe Anhang). Dann den Package Build als Release-Build auswählen (sonst werden die obj in ein Unterverzeichnis gesteckt, was dann in allen Projekten zusätzlich im Suchpfad aufgenommen werden muss). Große Einschränkung: ich hatte ein eigenes Package, wo eine (fremde) Kompo nur im Debug ein obj erstellt bekam. Die Ursache kenne ich nicht.

3. Den Builder starten und kontrollieren, ob die soeben kompilierte Kompo verfügbar ist. Falls nicht, Designtime-bpl unter Komponente/Packages installieren.

4. Danach den Builder nochmal öffnen und eine Kompo aufs Formular ziehen und dann kompilieren. Bei einigen Packages ging es, bei anderen wurde nach der passenden lib gefragt, die aber von Delphi miterstellt wurde und meist unter Gemeinsame Dokumente versteckt war.

Vielleicht schaut das nochmal jemand durch, der da mehr Wissen hat (eine Anleitung dazu habe ich bisher nicht gefunden), dann hätten wir es mal dokumentiert.

Grüße, Messie

[Muetze1]

Wo du es gerade erwähnst, das hatte ich schon vergessen. Wir haben in allen Packages im Pre-Build Script ein paar Shellkommandos eingetragen um die die falsch abgelegten *.obj, *.lib, *.hpp und *.bpi in die jeweiligen richtigen Verzeichnisse zu verschieben. Die Ausgabepfade ignoriert der Compiler dabei stur. Anscheinend wird dem C++ Compiler bzw. Linker nicht die Optionen von Delphi durchgereicht. Auch setzt die IDE die angegebenen Ausgabepfade zu gerne beim Öffnen des Packages zurück.