Ich habe projectA, in das ich eine Bibliothek mit importiere:
%Vor% Ich verwende dann foo an mehreren Stellen innerhalb des Projekts, und alles funktioniert gut.
Einige Verzeichnisebenen nach unten Ich möchte eine Bibliothek exportieren, die in diesem Projekt erstellt wurde, um sie in einem anderen Projekt mit einer vollständig getrennten CMake-Konfiguration zu verwenden. Ich habe:
%Vor% Das importierende ProjektB benötigt ebenfalls foo (weil die importierte Bibliothek es benötigt) und beschwert sich darüber, dass es cannot find -lfoo ist. Ich habe versucht, es zum Befehl export hinzuzufügen, aber dann bekomme ich:
Ich möchte nur die gleiche Konfiguration exportieren, die ich lokal für das andere (importierende) Projekt verwende. Ich möchte ProjectB nicht explizit über foo sagen müssen. Gibt es einen Weg, dies zu erreichen?
Ich habe keine tatsächliche Lösung für das Problem gefunden, wie angegeben, aber ich poste meinen eigenen Workaround für zukünftige Referenz.
Ich habe festgestellt, dass die foo Abhängigkeit beim Export ausgegeben wurde ; Es hatte einfach keinen Weg damit. Und da ich immer noch nicht herausgefunden habe, wie man CMake dazu bringen kann, den Pfad zu exportieren, habe ich meinen export -Befehl auf den in der obigen Frage gezeigten zurückgesetzt (ohne foo ).
Dann ging ich zurück zum ursprünglichen Ort, an dem foo importiert wurde, und entfernte die add_library und set_property und ersetzte sie durch:
Dann änderte target_link_libraries zu:
Mit anderen Worten, anstatt es zu einer echten "importierten Bibliothek" zu machen, ist es nur ein roher Bibliothekspfad. Dies wird korrekt in die Exportdatei geschrieben und ermöglicht es ProjectB, eine Verknüpfung herzustellen.
Sie müssen
foo von der Stelle, an der es erstellt wurde (z. B. foolibs.cmake ) Anstatt /path/to/thislib.cmake direkt zu verwenden (die von export(TARGETS thislib... generierte Exportdatei erstellt eine weitere, thislib-and-deps.cmake , die beide enthält:
Ich kann auch keinen idealen Weg finden, dies zu tun. Aber hier ist die Problemumgehung, die ich für jetzt verwende. Es ist zusätzliche Arbeit, und nicht DRY, aber ich denke, es bringt das Richtige.
Stellen Sie sich vor, dass lib B von der lib A von Drittanbietern abhängt. A hat entweder ein Suchmodul definiert oder wir können ein benutzerdefiniertes Suchmodul für dieses Modul implementieren. Beide sind machbar. Angenommen, wir haben FindA.cmake bereits geschrieben und in ${CMAKE_SOURCE_DIR}/cmake gespeichert. Nehmen wir an, dass Sie, wenn Sie cmake ausführen, um das Build-System von B zu generieren, A_ROOT angeben, um cmake bei der Suche nach A zu unterstützen.
Dann brauchen wir in B's Top-Level CMakeLists.txt :
Jetzt in cmake/BConfig.cmake :
Um die Lösung nach Hause zu bringen, schauen wir uns ein zweites Beispiel an, Rocket , diesmal mit Boost , das bereits ein Suchmodul definiert hat.
CMakeLists.txt :
Dann hätte cmake/RocketConfig.cmake :
Also ja. Es scheint wie zu viel tippen. Es scheint, als ob cmake in der Lage sein sollte, den gesamten Code von einer export -Anweisung in CMakeLists.txt zu generieren. Aber diese Strategie scheint das Ziel zu erreichen.
Ich habe auch noch nicht getestet, aber ich vermute, dass wenn Ihre transitive Abhängigkeit CONFIG anstelle von MODULE für find_package verwendet, es sehr einfach sein sollte, einfach zu CMAKE_PREFIX_PATH in hinzuzufügen Ihre Konfigurationsdatei auch.
Tags und Links cmake