cmake и папка с исходниками.

sourses

Положи CMakeLists.txt в папку sourses, а папкой выше в CMakeLists.txt напиши «add_subdirectory(sourses)».

Таки так делать ай яй яй.

В итоге рано или поздно один CMakeLists.txt (если он один) превращается в дичайшую какашку.

Именно поэтому тот же FILE(GLOB) по умолчанию не рекурсивный, что бы шаловливые руки не тянулись так сказать.

Разделяй и властвуй...

почему лучше не собрать все файлы в список и пройтись по ним в конце добавляя папку?

Потому, что у тебя наверняка ещё нету тестов, замеров покрытия кода, генерации доки и что там тебе ещё потом захочется прикрутить.

Ещё, потому, что если ты захочешь потом переместить эти файлы, получишь больше геморою.

Ещё, потому, что такой подход от тебя будет ожидать человек, уже работавший с CMake, ибо де-факто, все порядочные люди делают так. И не только в CMake, но и в пресловутом autotools и вообще в любом проекте, который хоть немного подрос.

А как надо? add_subdirectory()?

А ещё, потому что есть aux_source_directory же :)

Угу.

Это простейшая инкапсуляция, на начальных порах ей можно следовать абсолютно слепо, но в итоге оно сохранит много времени.

Принцип такой же как в высокоуровневых языках программирования - обьявляйте переменные, ближе к месту использования.

Ессно из этого правила есть исключения, особенно в чём то гибридном типо крестов. Но пока не понимаешь разницу, лучше получить небольшую избыточность в масштабировании, чем наоборот.

И алыверды add_subdirectory != project.

В поддиректории могут быть отдельные цели, да, но если задуматься, то кроме публичных инклудов, и ловить на уровень выше им нечего. Все цели, в рамках одного CMake проекта(не project, а корневого CMakeLists.txt) - резолвяться по имени. Поэтому если где то в проекте готовиться libMyCoolStuff:

#any subdir's CMakeLists.txt
target_link_libraries(myExe MyCoolStuff)

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

Я для себя написал модуль, который таскаю за проектами, что-то типа:

add_sources(PREFIX foo
    ROOT_DIR "sources"
        source_one.cpp
        source_two.cpp

    ROOT_DIR "other/sources"
        source_three.cpp
        source_four.cpp
)

add_executable(foo ${foo_SOURCES})

Так пользуйтесь add_subdirectory(), тем более что сейчас добавили возможность не собирать из подпроекта статическую библиотеку, а использовать его как коллекцию обьектников: add_library(foo OBJECT source_one.cpp source_two.cpp).

Предложение пользоваться add_subdirectory() естественно автору треда.

Можно - только зачем.

Обычно если что то вынесли в отдельную директорию на уровне сорцов, то это и на уровне бинарей - отдельная сущность.

Обычно если что то вынесли в отдельную директорию на уровне сорцов, то это и на уровне бинарей - отдельная сущность.

Отнюдь. Если что-то вынесли в отдельную директорию, то это разделение пространства имён, но не обязательно отдельная библиотека.

Имеет смысл сделать это статической библиотекой, хотя бы ради скорости пересборки тестов.

И опять же - разве новое пространство имён не привносит новую сущность? Если нет, значит что то не так с декомпозицией.

Это всё конечно дело вкуса, но когда сорцов много - такие нюансы начинают играть роль, не зря CMake, а не что то ещё (есть штуки с более вкусным синтаксисом), стал столь популярен.

Именно флоу, который толкает пилить в таком стиле хорошо подходит для плюсов с их, мягко говоря не спешной скоростью сборки.

Имеет смысл сделать это статической библиотекой, хотя бы ради скорости пересборки тестов.

Если тесты собираются в отдельной диретории того же проекта, то вместо STATIC стоит использовать OBJECT, это будет работать быстрее. Кроме того при линковке статической библиотеки не будут включены неиспользуемые переменные и, как следствие, их код инициализации.

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

Ну, возможно ты и прав, насчет декомпозиции.

С обьектниками врят ли оно будет быстрее, если они не менялись, ибо линкер будет каждый раз проделывать всю туже работу что при линковке статической либы. Я может не ясно выразился, но толкал я именно про инкрементальную сборку.

И все таки, как лучше это делать если каталогов с исходниками проекта много, и в каждом штук по 10-15 файлов? Как это удобнее? неужеле в каждый каталог пихать CMakeLists.txt и в в корневом конфиге к каждому указывать add_subdirectory() с именем каталога?

Вот я тоже сейчас над этим бьюсь как и автар, но пока выше описанное подходит. Но в каждом каталоге конфиг мне кажется это очень неудобно.