Problem Verknüpfen von Objektdateien aus dem Projekt in Tests

Question

Ich versuche, einige der Objektdateien zu verknüpfen, so dass ich Tests mit UnitTest ++ in der Codelite IDE schreiben kann. Mysteriös, die tutorial sagt nicht, wie man .o Dateien von einem (anderen) Projekt benutzt. Wenn ich die Befehlszeile verwendete, zeigt this thread mir, wie das geht. Allerdings habe ich größere Schwierigkeiten im Codelite-Editor. Die angenommene Antwort in this other thread sagt "[i] in der IDE des CodeLite, dieses wird in der Optionsbox des Linkers hinzugefügt," jedoch finde ich nicht, dass das der Fall ist.

Ich füge den Pfad zu diesen .o Dateien in der Library Search Path Stelle, und dann füge ich den Namen der einzelnen Dateien in der Libraries Stelle direkt darunter. Wenn ich das tue, bekomme ich den /usr/bin/ld: cannot find -l<stuff> Fehler. Wenn ich die Namen der spezifischen Dateien in der Library Stelle weglasse, bekomme ich den undefined reference to Fehler.

Muss ich das ursprüngliche Projekt als Bibliothek kompilieren, um dies zu umgehen? Oder gibt es eine Lösung, die ich nicht sehe? Die my_class_test.cpp Datei, die ich ausführen möchten sieht ungefähr so ​​aus:

#include <UnitTest++/UnitTest++.h> 

#include "my_class.h" 

SUITE(MyClassTest) 
{ 

class MCFixture 
{ 
public: 
    MyClass me; 
    MCFixture() : me("a", "b", "c") {}; 
}; 

TEST_FIXTURE(MCFixture, ConstructorTest) 
{ 
    CHECK_EQUAL(1.0, 1.0); 
} 

} //SUITE(MyClassTest) 

Answer 1

Codelite geht davon aus, dass die Namen, die Sie in Bibliotheken Feld schreiben sind Werte, die Sie an den Linker -l Option übergeben wollen .

Die Linkeroption -lfoo leitet den Linker, zuerst in den Verzeichnissen suchen Sie mit der -Ldir Option, dann in den Standardsuchverzeichnissen, für eine der beiden Dateien libfoo.so (eine gemeinsam genutzte Bibliothek) oder libfoo.a (ein statischen angeben Bibliothek). Es hört auf zu suchen, wenn es eines findet. Wenn es beide oder dasselbe im selben Suchverzeichnis findet, wird es libfoo.so bevorzugen. Die ausgewählte Bibliothek wird, falls sie gefunden wird, in die Verknüpfung eingegeben. Ansonsten der Linker wird einen Fehler geben: cannot find -lfoo.

Also, wenn Sie ein Linker-Suchverzeichnis angegeben haben - /home/me/other/project/Debug, sagen - und in den Bibliotheken Box haben Sie eingegeben vielleicht foo.o, bar.o, dann wird der Linker nach Dateien suchen wird:

/home/me/other/project/Debug/libfoo.o.{so|a} 
/home/me/other/project/Debug/libbar.o.{so|a} 

, die nicht vorhanden sind, und Sie gehen zu sagen: cannot find -l{foo|bar}.o

Es ist eine Variation der -l Option, -l:name, whi ch weist den Linker an, dass name der genaue Name der Datei ist, nach der gesucht werden soll. Also, wenn entfernen Sie foo.o, bar.o aus den Bibliotheken Feld und geben Sie ein:

-l:foo.o 
-l:bar.o 

in den Linkers Optionen Feld Ihre Verknüpfung erfolgreich sein wird (abgesehen von anderen Fehlern).

Natürlich foo.o und bar.o sind Objektdateien, nicht Bibliotheken, entweder statisch oder dynamisch , so die Verknüpfung Nötigung mich in der Bibliothek Suche zu finden, ist ein bisschen eine Flickschusterei, auch wenn Sie es richtig machen.

Es scheint, dass Sie ein Anwendungsprojekt geschrieben haben und jetzt möchten Sie ein anderes Projekt zu Unit-Test-Funktionen und/oder Klassen von der Anwendung verwendet schreiben.

Dies ist eine Binsen Situation, auf die die Standardlösung ist drei Projekte:

• A Projekt: Baut eine (statisch oder gemeinsam) Bibliothek, die die Komponenten implementiert werden getestet und exportiert ihre APIs.
• Projekt B: Baut Ihre Anwendung, #include -Ing die Header-Datei (en) und die Verknüpfung die Bibliothek aus dem Projekt A.
• Projekt C: Baut den Unit-Test-Läufer, auch #include -Ing die Header-Datei (en) und die Verknüpfung der Bibliothek von Project A.

machen Projekte B und C auf Projekt A. abhängen In Codelite Sie dies mit den Build-Auftrag Projekteinstellungen tun können.

Sie werden feststellen, dass diese Lösung längerfristig wartungsfreundlicher ist als die Verknüpfungsoptionen des Unit-Test-Runner auf dem neuesten Stand mit den Objektdateien zu halten, die von Ihrer Anwendung generiert werden.