Я нашел своего рода хак, чтобы хотя бы выводить четко структурированную информацию о том, какая цель зависит от каких предпосылок. Минус в том, что это довольно навязчиво. Другими словами, вам нужно изменить свой 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
, очевидно, не выполняет рецепт сборки цели, которую он считает, от -до -. ] Дата.
Экспортировать:
typeset -xf inner_function
Пример:
#! /bin/bash
inner_function () { echo "$1"; }
outer_function () { bash -c "echo one; inner_function 'two'"; }
typeset -xf inner_function
outer_function
Другие способы написать то же самое: export -f inner_function
или declare -fx inner_function
.
Обратите внимание, что экспортированные функции оболочки являются a)функцией bash -, не поддерживаемой в других оболочках и b)по-прежнему вызывают споры, даже после того, как большинство ошибок было исправлено после контузия .
Когда мне нужна одна и та же функция в нескольких сценариях, я помещаю ее в дополнительный файл сценария «библиотеки» и «исходный»(source the_lib_script
или. the_lib_script
)в сценариях, которым нужна функция.