Организация структуры каталогов в cmake проектах

0

2

Дано: пол сотни программ и ещё пол сотни библиотек, которые используются этими программами.

Вопрос: как лучше всего организовать этот проект.

Цель: минимизировать время компиляции.

Само собой напрашивается решение вида:

./programs/a/CMakeLists.txt:
add_subdirectory("../../libs/blib")
add_subdirectory("../../libs/clib")
...
./programs/b/CMakeLists.txt:
add_subdirectory("../../libs/blib")
add_subdirectory("../../libs/dlib")
...

Очевидно, что мне не нравятся относительные пути. Так же для каждой программы придется собирать требуемые ей библиотеки отдельно. (Но зато каждая программа собирается отдельно в своем binary dir)

Вариант два: добавить один cmake и в нем подоьавлять все программы. Проблема: свалка всего и возможно неоправданно длинный этап конфигурации. Проблему относительных путей не рещает.

Посоветуйте best practices и может какие-то красивые решения.

Ссылка

←	Я дико извиняюсь, но вопрос про javascript: binary input stream?

<<Университетский>> краткий курс программирования

→

В корневом каталоге главный CMakeLists файл, который заинклудит все библиотеки, а программы можно собирать по флагам.

~~a1batross~~ ★★★★★
(18.08.19 12:59:22 MSK)

Ответ на: комментарий от a1batross 18.08.19 12:59:22 MSK

Ну как бы мне не хочется собирать все библиотеки без надобности. То есть программа лучше знает о своих зависимостях.

Либо нагородить что-то типа макроса my_find_package, который будет более гибким чем add_subdirectory и в нем не будут захардкодены пути...

invy ★★★★★
(18.08.19 13:40:49 MSK) автор топика

Что плохого в относительных путях? Всяко лучше, чем абсолютные

KivApple ★★★★★
(18.08.19 14:01:15 MSK)

Ответ на: комментарий от KivApple 18.08.19 14:01:15 MSK

Если структура проекта меняется - все разваливается. Если бы все необходимые библиотеки были а подкаталогах - другой вопрос.

invy ★★★★★
(18.08.19 14:53:39 MSK) автор топика
Последнее исправление: invy 18.08.19 14:54:29 MSK (всего исправлений: 1)

Ссылка

Ответ на: комментарий от a1batross 18.08.19 12:59:22 MSK

Хотя в принципе норм. Собирать по частям выбирая нужный target.

Вроде не плохой пример.

https://cliutils.gitlab.io/modern-cmake/chapters/basics/structure.html

https://gitlab.com/CLIUtils/modern-cmake/blob/master/examples/extended-projec...

invy ★★★★★
(18.08.19 15:12:37 MSK) автор топика
Последнее исправление: invy 18.08.19 15:15:01 MSK (всего исправлений: 2)

Ответ на: комментарий от invy 18.08.19 13:40:49 MSK

Тогда лучше распилить репозиторий на пачку мелких. Ну а чо, зато красиво!

~~a1batross~~ ★★★★★
(18.08.19 15:43:50 MSK)

Ссылка

Ответ на: комментарий от invy 18.08.19 15:12:37 MSK

Ещё можно попробовать библиотеки определять с опцией EXCLUDE_FROM_ALL, чтобы собирались только библиотеки нужные для выбранных программ.

Begemoth ★★★★★
(18.08.19 17:24:57 MSK)

Ответ на: комментарий от Begemoth 18.08.19 17:24:57 MSK

Хорошая идея кстати

invy ★★★★★
(18.08.19 17:46:49 MSK) автор топика

Ссылка

Посоветуйте best practices и может какие-то красивые решения.

Не использовать дремучие версии CMake.
Оформить либы в отдельных директориях с COMPONENT и EXCLUDE_FROM_ALL в install(). См [пример].(https://habr.com/ru/post/461817/#installation).
Подумать/попробовать install(EXPORT) и подключать либы через find_package().
Если есть либы, которые 100% используются только одной прогой или другой либой, то их обычно удобнее размесить в под-директории соответствующего компонента.

Deleted
(19.08.19 13:54:15 MSK)