Лекции

Разбираем, почему в C++ сборка быстро становится отдельной задачей: от многофайловых проектов со .cpp/ .hpp и папками include/, src/ до типичных ошибок компиляции и линковки. Показываем роль «дирижёра» над компилятором и линкером, объясняем кроссплатформенность (Visual Studio / Make / Ninja / Xcode) и фиксируем правильную модель: CMake — это описание проекта и его targets, а не «ещё один компилятор».

Разбираем «скелет» CMake-проекта для C++: зачем нужен файл CMakeLists.txt, что делает команда project(...), как объявить цель через add_executable(...), почему важно фиксировать стандарт через target_compile_features(...) и как диагностировать типичную линковочную ошибку undefined reference, если забыли добавить .cpp в сборку.

Разбираем, почему «глобальная магия» вроде CMAKE_CXX_FLAGS и include_directories плохо масштабируется, и как перейти к дисциплине target‑подхода: задавать стандарт через target_compile_features (например, cxx_std_23), макросы — через target_compile_definitions, а предупреждения и флаги компилятора — через target_compile_options. Отдельно фиксируем идею видимости требований ( PRIVATE/ PUBLIC/ INTERFACE) и собираем мини‑проект MiniCalc.

Разбираем, как CMake задаёт include‑пути для конкретных целей через target_include_directories: почему компилятор не «видит» заголовки без настроек, чем отличаются области видимости PRIVATE/ PUBLIC/ INTERFACE, как include‑пути становятся транзитивными для потребителей через target_link_libraries, и как отделять публичный API ( include/) от внутренних заголовков реализации ( src/).

Разбираем, как в CMake работает линковка target’ов через target_link_libraries, почему # include не «подтягивает» реализацию, чем отличаются PRIVATE/ PUBLIC/ INTERFACE, и как CMake протаскивает (или не протаскивает) требования по графу зависимостей. На практике собираем пример с библиотеками cli и calc и учимся диагностировать undefined reference.