Проєкт із кількома файлами: перелік джерел і file(GLOB)

У лекції про перший проєкт збирався один main.cpp. Реальні програми розділені на модулі, і кожен модуль — це пара .h та .cpp (тема про багатофайлові програми). Тут розглянемо, як повідомити про всі ці файли CMake.

Приклад проєкту

Програма складається з трьох одиниць трансляції: main.cpp, math_utils.cpp і string_utils.cpp. Заголовки до одиниць трансляції не додаються окремо, бо компілятор бере їх через #include.

Усі три .cpp компілюються окремо і лише потім лінкуються. Якщо якогось з них не буде в add_executable, компіляція пройде, а лінкер повідомить про невизначені символи (undefined reference або LNK2019 у MSVC).

Спосіб 1: явний перелік усіх файлів

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

add_executable(MyProject
    main.cpp
    math_utils.cpp
    math_utils.h
    string_utils.cpp
    string_utils.h
)

Файли перелічені прямо в add_executable, по одному в рядку. Заголовки .h додавати не обов'язково для збірки, але корисно: IDE (Visual Studio, CLion) показує їх у дереві проєкту і не плутає з зайвими файлами.

Це найпростіший і найпрозоріший варіант. Під час код-рев'ю в git diff одразу видно, що додано новий файл.

Спосіб 2: змінні SOURCES і HEADERS

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

# Список вихідних файлів
set(SOURCES
    main.cpp
    math_utils.cpp
    string_utils.cpp
)

# Список заголовкових файлів (необов'язковий, для IDE)
set(HEADERS
    math_utils.h
    string_utils.h
)

add_executable(MyProject ${SOURCES} ${HEADERS})

Результат той самий, але списки винесені в змінні. Зручність у тому, що перелік можна використати в кількох місцях: наприклад, зібрати з тих самих SOURCES і виконуваний файл, і тестову програму, або додавати файли до списку умовно:

if(WIN32)
    list(APPEND SOURCES windows_specific.cpp)
endif()

Спосіб 3: автоматичний пошук через file(GLOB)

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

# Знайти всі .cpp файли в поточній папці
file(GLOB SOURCES "*.cpp")

# Знайти всі .h файли
file(GLOB HEADERS "*.h")

add_executable(MyProject ${SOURCES} ${HEADERS})

Команда file(GLOB ЗМІННА маска) шукає файли за маскою і записує знайдений список у змінну. Додавати файл у CMakeLists.txt вручну не потрібно. Спокуслива зручність, але з нею пов'язана проблема.

Чому GLOB ризикований

Пошук виконується один раз, під час конфігурації. Якщо після цього створити новий .cpp, система збірки про нього не дізнається: вона не знає, що список файлів міг змінитись. Перевіримо це на нашому проєкті:

Тільки після ручної повторної конфігурації logger.cpp потрапив у збірку. Така поведінка дає плутанину в команді: колега додав файл, ви зробили git pull, зібрали проєкт, і лінкер видає помилку «undefined reference», хоча код правильний. Причина прихована в кеші.

CONFIGURE_DEPENDS: компроміс

CMake 3.12 додав прапорець CONFIGURE_DEPENDS. З ним система збірки при кожній збірці повторно перевіряє маску і запускає конфігурацію, якщо список файлів змінився:

file(GLOB SOURCES CONFIGURE_DEPENDS "*.cpp")

Результат на тому ж проєкті:

Нові файли підхоплюються без ручної повторної конфігурації. Платою за це є додаткова перевірка файлової системи при кожній збірці. На великих проєктах і повільних мережевих дисках це помітно, а в документації CMake зазначено, що не всі генератори надійно її підтримують. Тому CONFIGURE_DEPENDS слід розглядати як пом'якшення проблеми, а не як її усунення.

Порівняння способів

Рекомендація: у реальних проєктах використовуйте способи 1 або 2. Спосіб 3 прийнятний для невеликих навчальних проєктів, де ви єдиний автор і готові перегенеровувати файли збірки.

Питання для самоперевірки

Практичне завдання

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_CXX_STANDARD 17)

set(SOURCES
    main.cpp
    math_utils.cpp
    string_utils.cpp
    logger.cpp
)

set(HEADERS
    math_utils.h
    string_utils.h
    logger.h
)

add_executable(MyProject ${SOURCES} ${HEADERS})

Резюме