Как отслеживать 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.