проблема

Я хочу увидеть зависимости для одной или нескольких целей make-файла. Поэтому я ищу программу, которая может анализировать make-файлы и затем представлять зависимости в некотором древовидном формате (отступ, ascii-art, ...) или в виде графика (точка, ...).

Аналогичный

Есть программы, которые делают это для других ситуаций:

• pactree или debtree могут отображать зависимости для пакетов программного обеспечения в соответствующем формате в виде дерева, такого как формат ascii или в виде dotграфика,
• gcc -M source_file.c отображает зависимости исходного файла C как правило make,
• pstree отображает ascii представление дерева процессов.

Прогресс

В поисках в интернете я нашла небольшую помощь . Это побудило меня попробовать

make --always-make --silent --dry-run some_target | \
  grep --extended-regexp 'Considering target file|Trying rule prerequisite'

но, похоже, мне нужно взломать еще какой-то код для разбора в perl или python, чтобы представить это как хорошее дерево / граф. И я пока не знаю, получу ли я действительно полный и правильный график таким образом.

Требования

Было бы неплохо ограничить график некоторыми способами (без встроенного правила, только с заданной целью, только с некоторой глубиной), но по большей части я просто ищу инструмент, который даст мне зависимости в некотором «разумном», человеческом -видимый формат (как и программы под «Аналог» делать).

Вопросов

• Есть ли программы, которые могут это сделать?
• Получу ли я полную и правильную информацию от make -dnq ...?
• Есть ли лучший способ получить эту информацию?
• Существуют ли сценарии / попытки анализа этой информации?

Попробуйте makefile2graph от того же автора, где вместо этого написан похожий инструмент MakeGraphDependencies .javac

make -Bnd | make2graph | dot -Tsvg -o out.svg

Затем используйте редактор векторной графики, чтобы выделить нужные соединения.

Я нашел способ взломать, по крайней мере, выводить четко структурированную информацию о том, какая цель зависит от каких предпосылок. Недостатком является то, что это довольно навязчиво. Другими словами, вам нужно изменить свой make-файл, чтобы обернуть рецепты сборки всех ваших целей в небольшую условную функцию. Я выложу краткий пример:

getRecipe = $(if $(DEPENDENCY_GRAPH),@echo Target $@ depends on prerequisites "$^",$(1))


VARIABLE_TARGET_NAME = foobar.txt

all : TopLevelTarget

TopLevelTarget : Target_A Target_D
    $(call getRecipe,\
        @echo Building target $@)

Target_A : Target_B
    $(call getRecipe,\
        @echo Building target $@)

Target_D : Target_C
    $(call getRecipe,\
        @echo Building target $@)

Target_B : $(VARIABLE_TARGET_NAME)
    $(call getRecipe,\
        @echo Building target $@)

Target_C :
    $(call getRecipe,\
        @echo Building target $@)

$(VARIABLE_TARGET_NAME) :
    $(call getRecipe,\
        @echo Building target $@)

В этом примере я использую свернутую вручную функцию getRecipe, чтобы обернуть рецепт каждой отдельной цели, а затем решить, нужно ли на самом деле запускать этот рецепт или просто выводить, какая цель строится и от каких предпосылок она зависит. Последнее происходит, только если переменная DEPENDENCY_GRAPHустановлена ​​(например, как переменная окружения). В этом примере, рецепт сборки - это не что иное, как эхо, говорящее о том, что цель строится, но вы, очевидно, можете заменить это командой по вашему выбору.

При DEPENDENCY_GRAPHзначении 1 это приводит к выводу:

Target foobar.txt depends on prerequisites ""
Target Target_B depends on prerequisites "foobar.txt"
Target Target_A depends on prerequisites "Target_B"
Target Target_C depends on prerequisites ""
Target Target_D depends on prerequisites "Target_C"
Target TopLevelTarget depends on prerequisites "Target_A Target_D"

который должен быть достаточно простым для анализа и последующего преобразования в точечный график.

Если значение DEPENDENCY_GRAPHвообще не установлено или равно 0, результат будет:

Building target foobar.txt
Building target Target_B
Building target Target_A
Building target Target_C
Building target Target_D
Building target TopLevelTarget

или, другими словами, вместо этого используется обычный рецепт сборки. Я еще не проверял, работает ли это надежно со сложными рецептами. Одна проблема, с которой я уже столкнулся, заключается в том, что она вообще не работает с многострочными рецептами.

Например, в рецепте сборки последней цели, если в дополнение к сообщению о том, что цель строится, я действительно хотел получить touchфайл:

$(VARIABLE_TARGET_NAME) :
    $(call getRecipe,\
        @echo Building target $@\
        touch $@)

makeкажется, кажется, что эта touch $@часть является просто частью эха в предыдущей строке:

Building target foobar.txt touch foobar.txt

Если я опущу обратную косую черту в предыдущей строке, назову makeжалобу *** unterminated call to function: «отсутствует». )'. Stop.Если у кого-то есть идея, как makeиграть хорошо, я весь в ушах. :)

РЕДАКТИРОВАТЬ: Другая проблема с этим подходом заключается в том, что он будет работать только в том случае, если результаты компиляции уже не существуют, поскольку, makeочевидно, не выполняет рецепт компоновки целевого объекта, который он считает актуальным.

Я использовал римейк --profile (замена для замены make), он генерировал дерево зависимостей в формате callgrind.

Затем gprof2dot может сгенерировать изображение целевого дерева.