Mehrer Bibliotheken zu einer DLL zusammenbinden
-
Hallo,
habe schon das Forum und das Netz ergebnislos dazu befragt:
Ich habe eine Visual Studio C++ Projektmappe mit mehreren Unterprojekten die DLLs bauen. Ein bestimmtes Unterprojekt (nennen wir es MyAPI) baut auf alle anderen DLLs auf. Als Ergebnis hätte ich gerne eine DLL (MyAPI.dll), die alle anderen DLLs enthält. Ich möchte also später nur diese eine DLL installieren anstatt mehrere DLLs. Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.
Mir ist noch nicht klar, wie ich das Ergebnis erreichen kann. Müssen alle, bis auf MyAPI.dll, statisch gelinkt und dann MyAPI hinzugefügt werden (wie?)? Oder gibt es eine andere offensichtliche Lösung?
Vielen Dank für eure Hilfe!
zussel
-
Mit einer statischen Bibliothek kannst Du es nicht erreichen, denn die einzelnen Bibliotheken wollen ja alle ihre Entry-Points haben. Du müsstest ja dann in der DLL ein Interface bauen, dass den statischen Code einbindet. Er würde ja sonst nicht gelinkt werden.
Ich würde ein großes neues Projekt bauen und die einzelnen Elemente in dieses Projekt einfügen.
Ganz verstehe ich aber nicht den Sinn. Wenn die einzelnen Bibliotheken jetzt schon als DLL vorliegen. Welchen Benefit versprichst Du durch die Zusammenführung?
Alleine der Kuddelmuddel mit den verschiedenen Projekteinstellungen würde mich abschrecken und auch die pflegbarkeit.
-
Hallo,
danke erstmal für die Antwort! Der Sinn und Zweck dahinter ist die Wiederverwendbarkeit. Ich habe in den einzelnen DLLs zum Beispiel allgemeine Funktionen zur Netzwerkkommunikation, XML Verarbeitung und Logging verpackt. Diese möchte ich auch in anderen Projekten wiederverwenden. Darum mehrere Unterprojekte. Wenn ich hinterher ein Setup daraus baue, soll aber nur diese eine "MyAPI" DLL herauskommen (nebst Header-Datei).
Vielleicht gehe ich das Problem aber auch von der falschen Seite an. Wenn ich allerdings alles in ein Projekt kippe und baue, ist ja erstmal alles in Ordnung. Dann arbeite ich aber irgendwann an einem zweiten Projekt und gehe genauso vor, stelle einen Fehler in einer diese "Basis" Bausteine (ehemals DLLs) fest und muss diesen dann in meinem ersten "MyAPI" Projekt nachziehen. Unschön! Daher habe ich eigenständige Projekte daraus gemacht.
Gruß,
zussel
-
Wieso hast Du ein Problem mit dem Pflegen, wenn alles in einer DLL ist.
Ich würde das Projekt natürlich so aufbauen, dass immer die gleichen Sourcedateien verwendet werden und diese nicht dupliziert werden!
Was heißt nächtes Projekt? Dann ändert sich doch nciht die MyAPI-DLL?
-
Hm, ich glaube, jetzt habe ich einen Knoten im Hirn. Folgende Situation, ich habe meine Basis DLL (MyBase) und zwei daruf aufbauende andere DLLs MyAPI und MyOtherAPI.
MyAPI <- MyBase -> MyOtherAPI
Wenn ich jetzt die Elemente in MyAPI und MyOtherAPI hinzufüge, dann sind diese doch doppelt vorhanden. Ausser ich habe die Elemente von MyBase an einer zentralen Stelle (da dachte ich jetzt an ein DLL Projekt). Aber ich denke Du meinst einfach nur den Quellcode, oder?! Bin mir aber nicht sicher, wie ich ein und den selben Quellcode in zwei Projekten verwalten kann.
Wenn der Quellcode aber dann noch in einem Repository liegt, fehlt mir noch die Verbindung zu den beiden einzelnen Projekten (MyAPI und MyOtherAPI).
Ich sag's ja, ich habe jetzt gerade einen Knoten im Hirn. Aber einen kleinen Schritt bin ich schon weiter...
Gruß,
zussel
-
Der Sinn von DLL ist ja nicht alles in einer zu haben.
Was wenn du in einem Projekt nur funktionen einer DLL brauchst denn dann wir der Rest auch geladen.
Was wenn es einen Fehler in einer gib.
Dann musst du alles neu erstellen. So lieferst du nur eine kleine DLL und keine große aus.
Ich habe für meine ein eigens verzeichnis wo die LIB und die DLL erstellt wird. Von dort linken alle anderen Projekte dazu.
Bedeutet das ich bei einem Fehler nur die Projekte neu erstellen muss wo die DLL verwendet wird.
SOllte es sich nur um einen Fehler in einer Funktion handeln dann muss man nichtmal alle projekte neue erstellen. Es reicht wenn die neue DLL ins Projekt geladen wird.
-
Natürlich ist es klar, dass mit einzelnen DLLs die Wartbarkeit viel einfacher ist. Deshlab habe ich es ja auch so implementiert.
Ziel ist es aber einem Dritten (zum Beispiel einem Kunden) eine DLL nebst Header an die Hand zu geben, mit der er weiterrarbeiten kann. Momentan muss ich ihm mehrere DLLs geben. Meine Frage ist, ob ich dass irgendwie vermeiden kann. Aber wahrscheinlich muss ich mich mit dem Gedanken anfreunden, dass er mehrere DLLs bekommt.
Gruß,
zussel
-
Jetzt verstehe ich Dein Problem.
Du kannst MyBaseDLL in eine statische LIB umwandeln. Solange diese keine Funktionen für MyAPI oder MyOtherAPI exportiert und nur intern genutzt wird, ist das OK.
Nun kanst Du
MyAPI, MyOtherAPI, und MySuperBigCombinedApi einfach aufbauen.Es gibt sogar noch eine Methode, die es einfach erlabt mehrere Zeile zu erzeugen und doch nur ein Projekt zu haben. Du baust einfach mehrere Projekt-Knfigurationen auf, die evtl. bestimmte Code-Dateien einfach weglassen oder anderen einbeziehen.
MySuperBigCombinedApi.DLL würde alle CPP Module einbeziehen.
MyAPI.DLL eben nur die aus MyAPI und MyBase
MyOtherAPI.DLL eben die aus MyOtherAPI und MyBase.Unsinnig wäre dies natürlich, wenn es Konstellationen gibt in denen MySuperBigCombinedApi und MyApi und/oder MyOtherAPI dennoch zusammen ausgeliefert werden müssten.
Es gibt viele Lösungen!
-
Das hört sich ja schon mal klasse an. Endlich versteht mich mal jemand
Wenn ich mein MyBase Bibliothek also statisch baue, kann ich sie zu meinen anderen DLLs dazulinken. Und zwar so, dass sie sie direkt enthalten. Ok, verstanden. Bleibt zunächst noch eine kleine Frage:
Kann ich die Bibliothek auch statisch bauen, wenn sie die MFC benutzt (ich vermutet mal ja)?
Dann werde ich mal versuchen, mein Projekt so abzuändern. Ich hoffe, ich finde in der Hilfe zum Visual Studio ein paar Hinweise.
Vielen Dank,
zussel
-
Schau Dir doch mal meinen letzten Ansatz an, mit dem mehreren Konfigurationen. Ich denke der kommt ganz ohne statische Libs aus und Du hast alles sauber in einem Projekt, was auch zusammen gehört.
-
Wenn ich Deinen letzten Ansatz richtig verstehe, dann gibt es eine Projektmappe, die erstmal nur einen Pool von Quelldateien enthält. Und je nach Projekt füge ich die benötigten Datein hinzu (innerhalb der Projektmappe). Das funktioniert so lange die einzelnen Projekte nicht auf einander aufbauen. Richtig?
Gruß,
zussel
-
Nein! Du hast ein Projekt und viele Konfigurationen. Du entscheidest in jeder Konfiguratin ob die entsprechende Quelldatei zum Projekt kompiliert werden soll.
Klick mal auf eine Sourcedatei, gehe auf Eigenschaften im Projekt-Explorer. Dort kannst Du wählen: Gehört zum Projekt, oder nicht (Exclude).
Das geht je Konfiguration...Dadurch hast Du mehrere Ausgabeverzeichnisse, für jede Konfiguration eins.
Aber alles ist ein projekt.
-
Ok, ich habe verstanden, dass Du es anders gemeint hast, aber noch nicht, wie es funktioniert
Wenn ich eine CPP Datei auswähle, sehe ich unter Eigenschaften "Zum Projekt hinzufügen". Ok, ist klar.Ich verstehe aber noch nicht, was Du genau unter Konfigurationen verstehst. Ist das eine Visual Studio Eigenschaft? Ich glaube, hier stehe ich noch auf dem Schlauch.
Gruß,
zussel
-
Wenn Du ein Projekt anlegst bekommst Du eine Debug und eine Release Konfiguration Version.
Siehe Menü Build -> Configuration ManagerMan kann aber weitere Konfigurationen basierend auf bestehenden Configurations anlegen. Klapp mal die erste Combobox auf. Also kannst Du eine Release BigDLL1 und Debug BigDLL1 Konfiguration hinzufügen. Und noch weitere Konfigurationen. Dabei werden auch die Ausgabepfade angepasst.
In jeder Konfiguration können auch andere Sourcedateien eingeschlossen werden. Somit könntest Du ales in ein Projekt packen, aber eben unterschiedliche Konfigurationen von DLLs aus dem einen Satz Sourcedateien heraus erzeugen.
Soetwas ist kann man dann auch noch sehr intelligent mit Compiler Präprozessor Defs kombinieren.Thats all..
-
Ah, jetzt verstehe ich. Unter Projekteigenschaften finde ich einen Konfigurationsmanager. Damit kann ich neben den Standard Debug und Release Konfigurationen noch eigene Erzeugen. Werde mich damit mal beschäftigen.
Dann habe ich in einem Projekt alle Dateien (zu MyBase und MyAPI usw.MyOtherAPI) Und erzeuge eine neue Konfiguration für MyAPI, die alle Dateien zu MyAPI und MyBase enthällt.
Puh, das ist echt eine schwere Geburt für mich. Aber man lernt nie aus. Da ist das Forum schon eine große Hilfe!
Gruß,
zussel
