Problem

Chcę zobaczyć zależności dla jednego lub większej liczby celów makefile. Szukam więc programu, który może analizować pliki makefile, a następnie będzie reprezentować zależności w jakimś drzewiastym formacie (wcięcie, ascii-art, ...) lub jako wykres (kropka, ...).

Podobny

Istnieją programy, które robią to w innych sytuacjach:

• pactree lub dług może wyświetlać zależności dla pakietów oprogramowania w odpowiednim formacie w drzewie jak format ascii lub jako dotwykres,
• gcc -M source_file.c wyświetla zależności pliku źródłowego C jako regułę make,
• pstree wyświetla ascii reprezentację drzewa procesów.

Postęp

Przeszukując Internet, znalazłem niewielką pomoc . To skłoniło mnie do spróbowania

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

ale wygląda na to, że muszę zhakować trochę więcej parsującego kodu w Perlu lub Pythonie, aby przedstawić to jako ładne drzewo / wykres. I nie wiem jeszcze, czy naprawdę w ten sposób uzyskam pełny i poprawny wykres.

Wymagania

Byłoby miło ograniczyć wykres w pewien sposób (brak wbudowanej reguły, tylko dany cel, tylko pewna głębokość), ale w przeważającej części szukam tylko narzędzia, które da mi zależności w pewnym „rozsądnym” ludzkim sensie -widoczny format (jak programy w „Podobne” zrobić).

pytania

• Czy są jakieś programy, które mogą to zrobić?
• Czy otrzymam pełne i prawidłowe informacje make -dnq ...?
• Czy istnieje lepszy sposób na uzyskanie tych informacji?
• Czy skrypty / próby analizy tych informacji już istnieją?

Spróbuj makefile2graph od tego samego autora, zamiast tego jest napisane podobne narzędzie MakeGraphDependencies .javac

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

Następnie użyj edytora grafiki wektorowej, aby podświetlić potrzebne połączenia.

Znalazłem rodzaj włamania, aby przynajmniej uzyskać jasno skonstruowane informacje o tym, który cel zależy od wymagań wstępnych. Minusem jest to, że jest dość nachalne. Innymi słowy, musisz zmienić swój plik makefile, aby zawrzeć receptury kompilacji wszystkich celów w małą funkcję warunkową. Podam krótki przykład:

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 $@)

W tym przykładzie używam ręcznie zwiniętej funkcji getRecipe, aby zawinąć recepturę każdego celu, a następnie zdecydować, czy faktycznie uruchomić ten przepis, czy po prostu wypisać, który cel jest budowany i od których warunków zależy. To drugie dzieje się tylko wtedy, gdy zmienna DEPENDENCY_GRAPHjest ustawiona (np. Jako zmienna środowiskowa). W tym przykładzie przepis na kompilację jest niczym więcej niż echem mówiącym, że budowany jest cel, ale można oczywiście zastąpić to poleceniem według własnego wyboru.

Przy DEPENDENCY_GRAPHustawieniu na 1 daje to wynik:

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"

które powinno być wystarczająco łatwe do przeanalizowania, a następnie przekształcenia w wykres punktowy.

Jeśli DEPENDENCY_GRAPHnie jest ustawiony wcale lub ustawiony na 0, wynikiem jest:

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

lub innymi słowy, zamiast tego używana jest normalna receptura kompilacji. Nie testowałem jeszcze, czy działa to niezawodnie ze skomplikowanymi przepisami. Jednym z problemów, na które już natknąłem się, jest to, że w ogóle nie działa z recepturami wieloliniowymi.

Na przykład w przepisie kompilacji ostatniego celu, jeśli oprócz stwierdzenia, że ​​cel jest budowany, naprawdę chciałem do touchpliku:

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

makewydaje się myśleć, że ta touch $@część jest jedynie częścią echa w poprzedniej linii:

Building target foobar.txt touch foobar.txt

Jeśli zostawiam ostatni odwrotny ukośnik w poprzedniej linii, makenarzeka na *** unterminated call to functionwezwanie: brak. )'. Stop.Jeśli ktoś ma pomysł, jak makegrać ładnie, jestem cały. :)

EDYCJA: Innym problemem związanym z tym podejściem jest to, że zadziała to tylko wtedy, gdy wyniki kompilacji już nie istnieją, ponieważ makeoczywiście nie wykonuje się przepisu kompilacji celu, który uważa za aktualny.

Użyłem remake --profile (zamiennik drop-in make), wygenerowało drzewo zależności w formacie callgrind.

Następnie gprof2dot może wygenerować obraz drzewa docelowego.