Verwalten/Verwenden von Bibliotheken mit Debug-Builds vs. Release-Builds

Question

Ich interessiere mich für alle Praktiken, wenn es darum geht, Bibliotheken für eine von Ihnen geschriebene Anwendung zu verwenden oder zu verteilen.

Zunächst, wenn Sie Ihre Anwendung entwickeln verknüpfen Sie die Debug oder Release-Version der Bibliotheken? (Wenn Sie Ihre Anwendung im Debug-Modus ausführen)

Wenn Sie Ihre App kurz vor der Bereitstellung im Freigabemodus ausführen, welche Builds der Bibliotheken verwenden Sie dann?

Wie führen Sie den Wechsel zwischen Ihrer Debug- und Release-Version der Bibliotheken durch? Tun Sie es manuell, verwenden Sie Makros oder was sonst noch tun Sie?

Answer 1

würde ich zunächst feststellen, welche Anforderungen aus der Bibliothek benötigt werden:

1. Debug/Release
2. Unicode-Unterstützung
3. Und so weiter ..

Damit bestimmt man kann dann Erstellen Sie Konfigurationen für jede Kombination, die Sie selbst oder andere Bibliotheksbenutzer benötigen.

Beim Kompilieren und Verknüpfen ist es sehr wichtig, dass Sie Bibliotheken und ausführbare Datei konsistent in Bezug auf Konfigurationen halten, d. H. Nicht mischen Release & debug bei der Verknüpfung. Ich weiß auf der Windows/VS-Plattform kann dies subtile Speicherprobleme verursachen, wenn Debug-& Release-Bibliotheken innerhalb einer ausführbaren Datei gemischt sind.

Wie Brian gegenüber Visual Studio erwähnt hat, empfiehlt es sich, den Konfigurationsmanager zu verwenden, um festzulegen, wie die einzelnen Konfigurationen erstellt werden sollen.

Zum Beispiel erfordern unsere Projekte die folgenden Konfigurationen abhängig von der ausführbaren Datei.

1. Debug + Unicode
2. Debug + ASCII
3. Mitteilung + Unicode
4. Veröffentlichung + ASCII

Die Nutzer dieses Projekt den Configuration Manager verwenden, um ihre ausführbaren Anforderungen mit dem übereinstimmen Projekt verfügbare Konfigurationen.

In Bezug auf die Verwendung von Makros werden sie ausführlich bei der Implementierung von Kompilierungszeitentscheidungen für Anforderungen verwendet, z. B. wenn die Debug- oder Release-Version einer Funktion verknüpft werden soll. Wenn Sie VS verwenden, können Sie das Attribut für die Präprozessor-Definitionen anzeigen, um zu sehen, wie die verschiedenen Makros definiert sind, z. _DEBUG _RELEASE, so steuert die Konfiguration, was kompiliert wird.

Welche Plattform verwenden Sie, um Ihre Projekte zu kompilieren/verlinken?

BEARBEITEN: Erweitern auf Ihren aktualisierten Kommentar ..

Wenn die Configuration Manager Option nicht verfügbar ist, dann empfehle ich die folgenden Eigenschaften aus dem Projekt mit:

• Linkers ->Zusätzliche Bibliotheksverzeichnisse oder Linkers ->Eingabe

Verwenden Sie das Makro $(ConfigurationName), um mit der geeigneten Bibliothekskonfiguration, z.B. Debuggen/Freigeben.

$(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.lib 

• Buildereignisse oder benutzerdefinierten Schritt Konfigurationseigenschaft

eine Kopie der Datei erforderlich Bibliothek Ausführen (n) aus dem abhängigen Projekt vor (oder nach) zu der Build vorkommend.

xcopy $(ProjectDir)\..\third-party-prj\$(ConfigurationName)\third-party.dll $(IntDir) 

Das Makro $(ProjectDir) wird für das aktuelle Projekt Standort ersetzt werden und bewirkt, dass der Betrieb in das aktuelle Projekt relativ kommen. Das Makro $(ConfigurationName) wird durch die aktuell ausgewählte Konfiguration ersetzt (Standard ist Debug oder Release), wodurch die richtigen Elemente kopiert werden können, je nachdem, welche Konfiguration gerade erstellt wird.

Wenn Sie eine reguläre Namenskonvention für Ihre Projektkonfigurationen verwenden, wird es helfen, wie Sie das $(ConfigurationName) Makro verwenden können, andernfalls können Sie einfach eine feste Zeichenfolge verwenden.

Answer 2

Ich benutze VS. Die Art und Weise, wie ich es mache, ist, dass die Bibliotheken, die ich brauche, durch die Referenzen des Projekts benötigt werden. Was im Grunde nur sagt, in welchem ​​Ordner man zum Zeitpunkt des Ladens nach einer bestimmten Bibliothek sucht. Ich entwickle meine Bibliotheken so, dass sie so projektunabhängig oder wiederverwendbar wie möglich sind. Deshalb sind sie alle eigene Projekte. So von den Bibliotheken, die ich für ein bestimmtes Projekt benötige, erstelle ich einen Ordner "3rdParty" oder "libs" auf der gleichen Ebene wie mein "src" -Ordner in meiner SVN-Ordnerstruktur. Ich neige dazu, nur freigegebene Bibliotheken zu verwenden, aber wenn ich einige unbekannte Probleme bekomme und zum Debugging wechseln möchte, kopiere ich manuell eine Debug-Version der Dateien im "lib" -Ordner und lade das Projekt neu.

Ich bin mir nicht sicher, ob ich sowohl debuggen als auch veröffentlichte Versionen in meinem Svn-Baum behalten sollte. Obwohl es sich um eigene Projekte handelt, ist es nicht richtig, sie im SVN-Baum eines anderen Projekts zu halten. Sie können jederzeit ohne Probleme wieder aufgebaut werden.

Und dann wollte ich einen Weg finden, den Schalter mehr zu machen ... hmmm ... naja im Prinzip automatisch wenn du das willst, aber das ist nicht was ich wirklich meine. Es fühlt sich einfach an, dass das manuelle Umschalten zwischen freigegebenen und debuggen nicht richtig ist. Vielleicht habe ich es noch nicht gefunden, aber was ich möchte ist eine Option, die wie folgt aussehen würde: Für Bibliothek "stack.dll" schauen Sie in "...... \ 3rdParty \" für die Veröffentlichung und "... ... \ 3rdPartyD \ "zum Debuggen.

Alles, was so etwas wie ich nicht weiß. Was schlagen Sie vor? Remember Bibliotheken sind externe Projekte. Da sind die gebauten Dateien komplett woanders. Denken Sie darüber nach, wenn Sie ein anderes Projekt auschecken, es erstellen und die erstellte Bibliothek kopieren, wenn Sie eine andere Kopie möchten. Wie würdest du das einrichten?