Я много работаю с CMake. И периодически сталкиваюсь с довольно сложными и запутанными CMake-скриптами. Долгое время я использовал логи, чтобы разобраться в их работе и выполнить отладку. Позже обнаружил, что в CMake есть встроенный отладчик и профилировщик, которые сильно упрощают процесс отладки. Кажется, не все знают об их существовании и о том, как с ними работать, поэтому я решил написать эту статью.
Отладка CMake-файлов
Начиная с версии 3.27 и выше, в CMake появилась возможность отладки.
Скачать нужную версию CMake можно отсюда (или собрать из исходников). Более новую версию CMake допустимо использовать, даже если ваши CMake-файлы написаны для старой версии (но будьте осторожны).
Если по какой-то причине вы не можете использовать CMake 3.27 и выше, то читайте вторую половину статьи.
Как настроить и использовать отладчик, я покажу на примере VSCode. Но полученную информацию вы сможете применить и в других IDE (например, CLion и Visual Studio)
Чтобы запустить отладку в VSCode:
Установите расширение CMake Tools.
Откройте необходимый вам проект.
Нажмите
Ctrl+Shift+P.В появившемся окне введите
cmake debugger.-
После чего вы должны увидеть два пункта меню:
Разница между пунктами только в том, что
Delete Cache…удаляет файлCMakeCache.txtи выполняет повторную конфигурацию проекта. Выберите необходимый вариант и нажмите
Enter.VSCode может дополнительно попросить указать компилятор и путь к исходникам. После этого отладчик должен запуститься.
Теперь вы можете пошагово отлаживать код, устанавливать breakpoint’ы и просматривать значения переменных:
К сожалению, с помощью отладчика нельзя отладить генераторные выражения.
Если отладка не запустилась
Если отладка не запускается или завершается с непонятной ошибкой, откройте вкладку OUTPUT в VSCode. Там выводится CMake-команда, которую использует отладчик:
По сути, плагин просто запускает cmake с необходимыми для отладки флагами, а затем подключается к его отладчику по DAP.
Обратите внимание на пути после флагов -S и -B:
-Sуказывает на папку с исходным кодом проекта;-Bуказывает на папку, куда помещаются файлы сборки.
Если эти пути отличаются от ваших, то их можно исправить в настройках VSCode. Для этого установите значения cmake.sourceDirectory и cmake.buildDirectory соответственно.
Также обратите внимание на флаг -G. Он определяет, какой используется генератор сборочной системы (Unix Makefiles, Ninja и другие). Его можно настроить с помощью опции cmake.generator в VSCode.
Если сборка вашего CMake-проекта должна запускаться с дополнительными параметрами, то необходимо перечислить их в cmake.configureArgs:
Или собрать проект привычным способом, а затем запустить отладчик, выбрав CMake: Configure with CMake Debugger. В этом случае отладчик будет работать с уже сконфигурированным проектом и переменными, сохраненными в CMakeCache.txt.
Если все настроено правильно, но отладка так и не заработала, сообщите об этом в комментариях — попробуем разобраться вместе.
Профилирование CMake
С версии CMake 3.18 также доступен профилировщик. С его помощью можно проанализировать последовательность выполнения команд, просмотреть вложенные вызовы и измерить время их работы.
Чтобы включить профилирование, добавьте в вашу команду генерации сборочной системы CMake следующие опции: --profiling-format=google-trace и --profiling-output=fileName.
Например, в результате вызова этой команды будет сгенерирован файл с именем trace:
cmake -B my_build --profiling-format=google-trace --profiling-output=traceДля просмотра trace-файла можно использовать любой chrome-based браузер или сайт ui.perfetto.dev.
Я покажу на примере Chrome. Откройте браузер, введите в адресной строке about:tracing и нажмите Enter. На открывшейся странице, нажмите кнопку Load и выберите trace-файл.
После этого файл должен открыться, и вы сможете просмотреть трейс:
Если есть темы в CMake, которые вызывают у вас боль, пишите в комментариях, и я постараюсь рассказать о них в следующих статьях.
Комментарии (0)
user-book
26.09.2025 08:30Ого, не знал даже о таком, хотя это и выглядит как "мы добавили компилятор в компилятор.."
Из личного опыта cMake уже давно шагает куда-то не туда. Он должен удобно описывать сборку, а не превращаться в надстройку и еще один язык программирования со своими особенностями и подводными
Для себя сформировал такую линейку сложности сборки:
bash - все просто и понятно. Даже если чего то не хватает или криво, то ты это поймешь. Проблемы могут быть но очень редко нерешаемые.
Makefile - эдакий наследник баш-скриптов. Сложности могут быть и первым камнем преткновения может вылезти то, как и откуда запускается этот самый мейкфайл в системе (что проблема потому как даже явное прописывание параметров запуска может не помочь по причинам). Даже если какие-то проблемы с мейкфайлом, всегда можно его "руками" упростить до простых консольных команд
cMake - оставь надежду всяк сюда всходящий. Версии, особенности, подпараметры и прочая срань. А еще подводные зависящие от того, как и где запускают и в каком именно режиме. А еще они очень легко превращаются в огромную запутанную вермишель кода, вермишель которая очень легко позволяет подключать файлы зависимостей из-за чего запутанность только преумножается
Жаль (и иронично) что лучшее на рынке, что придумали для сборки сложных и разноплановых сишников это обертки на питоне.
alexey_lukyanchyk Автор
26.09.2025 08:30Он должен удобно описывать сборку, а не превращаться в надстройку и еще один язык программирования со своими особенностями и подводными
Отчасти я согласен. Но CMake изначально был надстройкой для упрощения кроссплатформенной сборки (аналог automake/autoconf).
Сейчас в CMake и правда добавили очень много всего. Но я не сказал бы, что это проблема. Ведь необязательно использовать весь функционал CMake. Что бы сделать простейший C/C++ проект, хватит CMake скрипта из трех команд: `project()`, `cmake_minimum_required()` и `add_executable()`.
Версии, особенности, подпараметры и прочая срань.
Да, с обратной совместимостью и правда бывают нюансы. Еще есть проблема того, что концепции использования CMake периодически меняются. И одни рекомендованные практики заменяются другими.
А еще подводные зависящие от того, как и где запускают и в каком именно режиме. А еще они очень легко превращаются в огромную запутанную вермишель кода, вермишель которая очень легко позволяет подключать файлы зависимостей из-за чего запутанность только преумножается
Думаю это сильно зависит от того, кто пишет CMake скрипты. На любом языке можно написать плохой код =)
Жаль (и иронично) что лучшее на рынке, что придумали для сборки сложных и разноплановых сишников это обертки на питоне.
Интересно, с таким я не сталкивался. Может есть примеры "оберток на Python для сборки сишников"?
user-book
26.09.2025 08:30Интересно, с таким я не сталкивался. Может есть примеры "оберток на Python для сборки сишников"?
то же platformio это чистый питон
Китайцы если соизволяют выложить в открытый доступ какие-то средства для сборки и отладки, то они на питоне в 9 случаев из 10 (исключения это чисто сишные тулзы)
По работе много раз сталкивался с тем что версионность накручивали на питоне как самый быстрый и безболезненный способ раскатывать сборки на разных платформах и под разные версии железок
Думаю это сильно зависит от того, кто пишет CMake скрипты. На любом языке можно написать плохой код =)
Я до сих пор вспоминаю SDK для poketbook которое не удалось завести даже в режиме отладки просто потому что иди нафиг, вот почему) Нигде больше не встречал настолько запутанных макарон для сборки (благо есть готовые докер образы для работы с этой сранью)
alexey_lukyanchyk Автор
26.09.2025 08:30platformio
Точно, забыл про него. Там они используют SCons. Он конечно написан на Python, но все же это не совсем "python скрипты для сборки". Хотя штука интересная, правда я никогда не использовал ее вне `platformio`.
Мне просто интересно, что именно делают в python скриптах. Делают подобие bash скриптов для вызова компилятора?
Китайцы если соизволяют выложить в открытый доступ какие-то средства для сборки и отладки
Вполне может быть. Хотя что касается китайских микроконтроллеров, то там чаще выкладывают проекты для Keil/IAR/CubeIDE.
user-book
26.09.2025 08:30при всей моей нелюбви к питону (и в VSC), platformio получился неплохим. Его возможности встраивания скриптов прямо в сборку и не только (логи например) прям киллер-фича.
в целом на питоне "рожают" мекйфал. То есть что бы одна команда на сборку вызывала сборку, сама определяя все что надо и в случае проблем говоря о них прямым текстом. На втором месте всякие тулзы для проверок, первичных заливок и тд, но опять таки все в одном месте и в рамках одного исходника который одинаково запускается на любой платформе без сюрпризов.
alexey_lukyanchyk Автор
26.09.2025 08:30при всей моей нелюбви к питону (и в VSC), platformio получился неплохим.
Тут я полностью солидарен =)
rivo
26.09.2025 08:30Собирал всякую opensource дичь и там часто встречается Meson. Он проще чем СMake и кросс-компиляция проходила всегда легче. Можно его поставить между 2)Makefie и 3)CMake в списке.
viordash
26.09.2025 08:30Спасибо, теперь знаю что и vscode это можно, а то раньше сложные cmake в плагине visualgdb отлаживал
alexey_lukyanchyk Автор
26.09.2025 08:30Я сам был сильно удивлен, когда узнал про эти фитчи =)
Про плагин не знал, спасибо. Очень интересно, что статья по вашей ссылке 2018 года. Хотя поддержка отладчика в CMake была добавлена только в 2023 году. Получается Visual Studio сделали какой-то свой отладчик. Хитро.
dejkunelena
первый раз про такое слышу, очень полезно!