Как правильно подключать модули одного уровня?

Question

[iihaarr]

Есть такая структура проекта:
Project
|—Src
|——Module A
|———CMakeLists.txt
|——Module B
|———CMakeLists.txt
|——CMakeLists.txt
|——Main.cpp
Модуль B использует данные из Модуля A. Так вот, как это указать в CMakeLists.txt в Модуле B?

Answer 1

[res2001]

Модуль B использует данные из Модуля A

Что за данные?

смаке оперирует целями и зависимостями, а не данными.
Зависимости можно указать с помощью add_dependencies, подключить библиотеку с помощью target_link_libraries.
Если у вас в каком-то из модулей генерируются какие-то данные, то, видимо, там есть custom_target - укажите его в зависимостях вышележащего уровня.

Comments

[iihaarr]

В модуле А есть публичный хедер с данными(Структура и константы. Это все примеры). Его хочу использовать в модуле B

[Александр Ананьев]

iihaarr, подключайте как статическую библиотеку

[Станислав Макаров]

iihaarr А как вы оформили этот публичный хедер с точки зрения CMake? Как res2001 правильно указал, CMake оперирует целями. Этот публичный хедер - он собственно чем является с точки зрения workflow сборки в C++? Он является публичным API какой-то библиотеки? Есть ли ещё хедеры? Есть ли компилируемая часть? Оформлено ли это в таргет? Что вы вообще называете "Модулем" - это самостоятельные таргеты (ну т.е. например Модуль А - это статическая библиотека, а Модуль B - исполняемый бинарь) или просто подпапки с файлами исходников?

Или может у вас в Модуле А просто константа описана вроде `set(MY_HEADER_PATH ...)`, и вы хотите к ней доступ получить из Модуля B, мы ж не знаем.

Вы настолько обобщили вопрос, что ответить на него более конкретно просто невозможно.

[iihaarr]

Станислав Макаров, Модули A и B собственные, main.cpp - бинарник, где используется модуль B. Я пытаюсь разобраться, как выстраивать структуру проекта модульно. Может не обязательно каждому модулю свой CMakeLists и достаточно просто своей папки?

[res2001]

iihaarr,

Может не обязательно каждому модулю свой CMakeLists

Не обзяательно.
Но так проще.
Модули оформляйте как статические библиотеки, в исполняемом файле указывайте их в target_link_libraries.
Заголовочный файл, объявляющий экспортируемые функции и типы библиотеки указывайте для таргета библиотеки как интерфейсный.
Примерно так:

Module A
add_library(modulea STATIC modulea.cpp modulea.h)
target_sources(modulea INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/modulea.h)
target_include_directories(modulea INTERFACE ${CMAKE_CURRENT_SOURCE_DIR})

main
add_executable(main main.cpp)
target_link_libraries(main modulea)

[res2001]

iihaarr, Если же модуль это header only библиотека, то в смаке для нее можно создать цель используя
add_library(... IMPORTED ...)

Рекомендую делать отдельные цели для любой сущности, которая теоретически может использоваться отдельно от основной цели, т.к. в развитии проекта может понадобится например написать тесты, сделать какие-то вспомогательные утилиты и т.п.

Смотрите документацию: https://cmake.org/cmake/help/v3.27/genindex.html

[iihaarr]

res2001, Сделал, как вы и написали, работает, но в main у меня хедеры подключается напрямую, а не moduleA/moduleA.h и тп. Почему так?

moduleA

project(moduleA)

file(GLOB_RECURSE SOURCES ./src/*.cpp)
file(GLOB_RECURSE PUBLIC ./include/*.hpp)
add_library(${PROJECT_NAME} STATIC ${SOURCES} ${PUBLIC})
include_directories(include)
target_sources(${PROJECT_NAME} INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include/moduleA.hpp)
target_include_directories(${PROJECT_NAME} INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)

moduleB

project(moduleB)

file(GLOB_RECURSE SOURCES ./src/*.cpp)

include_directories(include)

add_library(${PROJECT_NAME} STATIC ${SOURCES})
target_sources(${PROJECT_NAME} INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_include_directories(${PROJECT_NAME} INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_link_libraries(${PROJECT_NAME} PRIVATE moduleA)

main

cmake_minimum_required (VERSION 3.8)

project(main)
add_subdirectory(moduleA)
add_subdirectory(moduleB)
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} moduleA moduleB)
set_target_properties(${PROJECT_NAME} PROPERTIES LINKER_LANGUAGE CXX)

[Станислав Макаров]

iihaarr

но в main у меня хедеры подключается напрямую, а не moduleA/moduleA.h и тп. Почему так?

О, так вы header namespace хотите себе сделать? А что вы для этого предприняли? У вас с помощью target_include_directories инклуд-папка выставляется в include, и непосредственно в ней и лежит moduleA.hpp. Откуда интересно должен появиться КАТАЛОГ moduleA? Его нужно для этого создать, например как в libuv делают. Правда тогда нет смысла называть хедер moduleA.hpp, раз он и так лежит в подпапке с таким именем (см. ту же ссылку с хедерами libuv, там как раз правильно сделано - один "общий" хедер uv.h и каталог uv со всеми остальными, которые уже имеют более специфичные названия).

[res2001]

iihaarr,

Почему так?

Потому что для цели modulea есть команда: target_include_directories(INTERFACE), которая при использовании библиотеки в другой цели автоматически добавляет указанную папку в поиск заголовочных файлов.
Если уберете target_include_directories, то надо будет писать include moduleA/moduleA.h
target_include_directories - добавляет к опциям компилятора опцию -I<указанный каталог>.

Параметр INTERFACE влияет не на саму цель, в которой он используется, а на цели зависимые от нее.