Как отслеживать CMakeLists.txt

Есть ли способ изучить, что делает cmake в неудачном прогоне? Например, у меня есть программа в зависимости от libbacktrace, с которой я могу ссылаться на gcc foo.c -lbacktrace. Но когда я пишу CMakeLists.txt как

cmake_minimum_required(VERSION 2.8)
find_library (BACKTRACE_LIBRARY backtrace)
message (BACKTRACE_LIBRARY=${BACKTRACE_LIBRARY})

и введите cmake <path>, он выведет BACKTRACE_LIBRARY=BACKTRACE_LIBRARY-NOTFOUND.

Как мне разобраться, где проблема? Какие команды выполняет cmake, прежде чем отказаться от поиска libbacktrace? Выполняет ли что-нибудь вообще? В autoconf все команды записаны в config.log, но CMakeOutput.log в этом случае пуст. Аналогично, cmake --trace только отгоняет содержимое CMakeLists.txt после кучи системных файлов cmake, что бесполезно в этом случае.

Обратите внимание, что я не ищу способ сделать этот конкретный вызов find_library work - это просто пример. Мой вопрос: у меня есть CMakeLists.txt, который работает не так, как ожидалось; какие инструменты существуют, чтобы помочь мне выяснить, где и почему это не удается?

Ответ 1

нет отладчика CMake или аналогичного. Что вы можете сделать, это:

Прочитайте вывод CMake, иногда он уже дает такие подсказки, как "missing INCLUDE_MYLIB_DIR" ). Удалите CMakeCache.txt и/или удалите каталог сборки, чтобы убедиться, что вы не пропустите вывод, потому что результат был кеширован. Повторите и проверьте, повлияло ли кэширование. Вы получаете больше предупреждений (которые предназначены для автора/разработчика CMake script, а не для пользователя) с -Wdev. Более полезными являются --warn-uninitialized, --warn-unused-vars и --check-system-vars, более подробную информацию см. В документации.
Проверьте сгенерированные файлы, такие как CMakeCache.txt и дополнительные файлы, которые вы создаете, как config.h или входные файлы для Doxygen. Переменные со значениями, которые вы ожидаете от других, являются индикаторами для дальнейших исследований.
Изучите CMakeError.log и CMakeOuput.log в подкаталоге CMakeFiles. К сожалению, многие тесты не записываются в эти файлы, но некоторые делают. Например, C-компиляторы запускают там вывод компилятора, который помогает найти проблему с непреднамеренными флагами или неправильными (кросс-компиляторами).
Отладка с printf. Это означает, что когда вы грубо знаете, где находится ваша проблема, выведите промежуточные переменные с помощью message. Это полезно, когда вы не знаете, как оценивается ветвь или подвыражение (часть выражения с AND или OR). Кроме того, вы можете размещать такие сообщения, как "в ветке, где версия mylib составляет > 3.2" внутри, чтобы следить за рабочим процессом.
Уменьшить сложность. Бросьте все, что вы не знаете, пока ваша проблема не исчезнет. Добавьте материал снова, пока проблема не появится снова. Иногда проще создать новый модуль, чтобы воспроизвести проблему с минимальным примером. Удивительно, но это часто помогает выявить проблему.
Отладка с --debug-output (для вывода отладки) --trace (полная трассировка) и --trace-expand (трассировка и расширенные переменные). Для них чрезвычайно полезно добиться прогресса в точке 5., потому что в противном случае вывод будет вас наводнять.

¹Ну, есть steveire CMake Daemon Tools. Я не использовал их сам, но они утверждают, что предлагают возможности для самоанализа, которые, похоже, довольно близки к отладчику.
Изменить: Теперь они называются CMake-server и будут частью CMake 3.7. Вы можете ожидать, что многие инструменты и IDE поймут это и улучшат способ разработки CMake.

Ответ 2

Рядом с указанным флагом --trace (и его переменным расширением sibling --trace-expand) существует --debug-output.

Из документов:

--debug-output
Поместите cmake в режим отладки.

Распечатайте дополнительную информацию во время выполнения cmake как трассировки стека с вызовами (send_error).

Это может дать вам необходимую информацию. Возможно в сочетании с --trace.