cmake: зависимости от библиотеки с обекти

Да приемем следната структура на директорията:

CMakeLists.txt
libA
    contents: a.cpp 
              a.h
src
    contents: hello.cpp
              target1.cpp
              target2.cpp
include
    - contents: hello.h

Имам статична библиотека A, използвана в основния изходен код на проекта.

Опит 1:

. . .
add_executable(t1 src/target1.cpp src/hello.cpp)
add_dependancies(libA)
target_include_directories(t1 PRIVATE ${PROJECT_SOURCE_DIR}/include
target_link_libraries(t1 PRIVATE /path/to/libA)
. . .

Това работи за t1, но ако искам да компилирам target2.cpp, ще трябва да повторя този процес, следователно hello.o се генерира два пъти.

Опит 2: Мислех да променя този подход, за да генерирам библиотека с обекти за hello.cpp и просто да добавя библиотеката с обекти към целите. И все пак получавам проблеми с компилирането, тъй като не може да намери заглавките, дефинирани в библиотека A, тъй като библиотеката с обекти се компилира първо и файловете с heade все още не са копирани в CMakeFiles.

. . .
add_library(libA src/hello.cpp)
add_executable(t1 src/target1.cpp $<TARGET_OBJECTS:libA>)
add_dependancies(libA)
target_include_directories(t1 PRIVATE ${PROJECT_SOURCE_DIR}/include
target_link_libraries(t1 PRIVATE /path/to/libA)
. . .

Има ли начин да се дефинира зависимост, така че статичната библиотека A да се компилира преди?


cmake
person Camilo Celis Guzman    schedule 17.01.2018    source източник
comment
Как редът на компилиране влияе върху това дали заглавките са намерени или не? Каква е връзката между обектните файлове и статичната библиотека? Опасявам се, че въпросът ви е доста неясен. Можете ли да добавите (подходящо минимизиран, но все пак демонстративен) пример за вашия CMake код?   -  person Angew is no longer proud of SO    schedule 17.01.2018
comment
@Angew благодаря ви за коментарите. Актуализирах въпроса. Дано сега е по-ясно. Аз съм доста нов в cmake, така че може да съм разбрал някаква основна концепция ужасно погрешно.   -  person Camilo Celis Guzman    schedule 17.01.2018
comment
и заглавните файлове все още не са копирани в CMakeFiles - къде, как и защо копирате заглавните файлове?   -  person Angew is no longer proud of SO    schedule 17.01.2018
comment
Казах това, тъй като libA всъщност е външен проект, който е включен в основния проект чрез ExternalProject_Add. Следователно всички файлове от библиотеката се копират в директорията CMakeFiles.   -  person Camilo Celis Guzman    schedule 17.01.2018
comment
Това е доста важна информация, която трябваше да бъде във въпроса от самото начало! Трябва да го редактирате.   -  person Angew is no longer proud of SO    schedule 17.01.2018
comment
само в случай, че add_library(Foo OBJECT ...) е библиотека с обекти и е много лоша идея да я използвате, тъй като не можете да използвате target_link_libraries върху нея, така че ако зависи от Bar, ще трябва да преминете: $<TARGET_PROPERTY:Bar,INTERFACE_INCLUDE_DIRECTORIES>, $<TARGET_PROPERTY:Bar,INTERFACE_COMPILE_OPTIONS>, $<TARGET_PROPERTY:Bar,INTERFACE_COMPILE_DEFINITIONS> на ръка, като използвате target_include_directories, target_compile_options и съответно target_compile_definitions   -  person Mizux    schedule 18.01.2018

Отговори (1)


arrow_upward
3
arrow_downward

В коментарите споменахте, че libA всъщност се въвежда в системата за изграждане с помощта на ExternalProject_Add. Което означава, че смесвате „нормални“ и външни проекти в един и същи CMakeLists.txt, а това е силно обезкуражено.

Предпочитаният начин за работа с ExternalProject е така нареченият подход Superbuild: третирайте всички проекти като външни и ги добавете с ExternalProject_Add, включително вашия собствен проект. По този начин главният CMakeList става просто суперкомпилация, контейнер и драйвер за подпроекти. На това ниво можете да въвеждате зависимости между отделните проекти, ако е необходимо.

Конфигурирайте и изградете суперсборката веднъж, за да настроите всички проекти правилно. След това отидете едно ниво по-ниско и работете върху проекта си, сякаш е самостоятелен; всички зависимости ще са вече подготвени и готови.

person Angew is no longer proud of SO    schedule 17.01.2018