Как я могу игнорировать присвоение переменной командной строки в рекурсивной сборке? - PullRequest
6 голосов
/ 01 июня 2009

Я пытаюсь склеить две системы сборки. Оба являются рекурсивными (правила в make-файле используют make для вызова других make-файлов для создания компонентов проекта).

Я назову их «A» и «B», где «A» создает приложение, а «B» - библиотеки, используемые «A».

Makefile верхнего уровня в вызовах A вызывает make TARGET = что угодно, что означает, что все рекурсивно вызываемые биты сборки наследуют значение TARGET как переменную только для чтения, включая систему сборки из B, которая называется как часть рекурсивной сборки.

Я не хочу, чтобы это происходило в системе сборки для 'B' (которая происходит из другого проекта), поскольку там make-файлы используют TARGET для своих собственных целей, и сборка завершается неудачно, поскольку TARGET имеет неправильное значение и читается -только.

Я вижу только два решения для этого, ни одно из которых не является палитрой;

1) Переименуйте TARGET во что-нибудь другое в make-файле в A, который устанавливает его, и в make-файлах в A, которые его используют, чтобы избежать конфликта с более низкими уровнями системы сборки.

2) Используйте директиву override везде в make-файлах в B, где установлена ​​переменная TARGET, чтобы переопределить ее состояние только для чтения.

У кого-нибудь есть идеи получше? - в идеале, я хочу, чтобы ничто не было унаследовано системой сборки B от A, кроме тех опций, которые я явно передаю в систему сборки B от A.

Кстати, я использую GNU Make v3.80.

Ответы [ 4 ]

3 голосов
/ 03 июня 2009

Вы можете установить MAKEOVERRIDES на ничего в make-файле второго уровня в A.

callb:
      cd subdir && $(MAKE) MAKEOVERRIDES=

Это передает обычные параметры командной строки, такие как -k и -s , но не определения переменных командной строки.

Или вы используете исторический MFLAGS , который совпадает с MAKEFLAGS , за исключением того, что MFLAGS не содержит определения переменных командной строки.

callb:
     cd subdir && $(MAKE) $(MFLAGS)

Подробности об этих двух опциях можно прочитать здесь: Руководство по эксплуатации GNU

0 голосов
/ 10 ноября 2011

Похоже, вы изменили make-файл A, чтобы рекурсивно вызывать make-файл B, и, следовательно, вашу проблему. Почему бы не ввести новый make-файл верхнего уровня, который рекурсивно вызывает make-файл B, а затем рекурсивно вызывает make-файл A? Например, комбинированный.mk:

all:
    $(MAKE) -f Makefile.B
    $(MAKE) -f Makefile.A

Таким образом, make-файл B ничего не наследует от make-файла A.

0 голосов
/ 03 июня 2009

В точке, где система сборки A вызывает систему сборки B, не используйте '${MAKE}' напрямую; вызвать сценарий оболочки, который вызывает сборку системы B (возможно, после очистки среды).

Чтобы добиться поведения, при котором команды выполняются с помощью 'make -n', добавьте префикс командной строки в make-файле к '+' (аналогично префиксу строки с '@' или '-' ).

0 голосов
/ 01 июня 2009

Возможно, вы можете использовать директиву «unsport», чтобы предотвратить распространение TARGET на make-файл B?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...