LINUX.ORG.RU

C++ header files layout в проекте и в деплойменте.

 ,


0

1

Всем привет. Есть cmake-проект с кучей подмодулей. В каждом подмодуле — свой header file, содержащий public API. При сборке я эти файлы копирую, допустим, в target/dist вместе с либой.

Инклудить из одного хидера другой я не могу: в проекте это будет #include "../common/common.h", а в dist оба хидера лежат в одном каталоге (допустим, dist/include) и должно быть #include «common.h». Создавать подкаталог под каждый хидер не хочется.

Но если не инклудить хидер из хидера, то в QtCreator 4.6.2 ClangCodeModel ругается на несуществующие символы. Надоедливый собака.

Что делать? Как вообще принято? Или может в 4.7 (Clang 6.0) это уже порешали, и надо только потерпеть чутка?

★★★★★

Ответ на: комментарий от xaizek

Да тоже вроде как геморрой на пустом месте. А если таких common несколько, то большой геморрой. :)

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Если у библиотеки есть зависимость от другой, то первой надо сказать, где лежит вторая. Может и геморройно, но вполне логично.

В GCC, например, правят инклюды перед их установкой, но мне кажется это костыльным.

xaizek ★★★★★
()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от xaizek

Ок. Я так понял, это и есть общепринятый подход. Спасибо.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А в cmake-проект тогда надо вписывать:

add_library(common STATIC ../../include/common.h aaa.cpp bbb.cpp)

Тоже думал, но не созрел.

dimgel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Не, буду-таки прописывать как xaizek посоветовал. В конце концов, пишу же я target_link_libraries(), вот аккурат над ним будет include_directories().

dimgel ★★★★★
() автор топика
Ответ на: комментарий от dimgel

Это решается объявлением переменной на нужном уровне.

set(PUBLIC_HEADER_DIR ${CMAKE_CURRENT_SOURCE_DIR}

А потом в коде модуля:

add_library(common STATIC ${PUBLIC_HEADER_DIR}/include/common.h aaa.cpp bbb.cpp)

anonymous
()

Оформлять каждый подпроект в виде либы с инклудами лежащими в директории вида:

root/subproject/include/subproject

В местах включения использовать как стороннее api:

#include <subproject/api.hpp>

В CMake файлах, либо сразу использовать find модули для api - это идеальный вариант, но потребует написания find модуля на каждый подпроект, зато проще потом будет выдрать api из дерева в отдельную библиотеку. Либо, просто прописывать инклуды в виде примерно:

include_directories("${CMAKE_SOURCE_DIR}/subproject/include")

Никаких относительных путей, хотя можешь попробовать и вспомнить меня если поделка взлетит и придётся её саппортить.

pon4ik ★★★★★
()
Последнее исправление: pon4ik (всего исправлений: 1)

Смотри в сторону target_include_directories(PRIVATE/PUBLIC) и target_link_libraries(PRIVATE/PUBLIC)

m0rph ★★★★★
()

Использовать подход, к примеру, принятый в Qt. Держать отдельную директорию с однострочными линками на реальный код:

include/foo/foo.h

#include "../../impl/.foo.h"

В настоящем foo.h использовать другие модули по системным путям:

impl/foo.h

#include <bar/bar.h>

В деталях реализации пользоваться относительными путями:

impl/foo.cpp

#include "foo.h"
#include "foo_private.h"

impl/foo_private.h

#include "foo.h"

При установке копировать содержимое include/foo/* с заменой файлов на те, на которые они ссылаются.

Dendy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.