Mehrer Bibliotheken zu einer DLL zusammenbinden
-
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
