Есть ли веские причины не использовать '#! / Bin / make -f' в начале make-файла для получения исполняемого make-файла?

Question

В основном для развлечения я создал makefile в своем каталоге $HOME/bin с именем rebuild.mk и сделал его исполняемым, а в первых строках файла было указано:

#!/bin/make -f
#
# Comments on what the makefile is for

...

all: ${SCRIPTS} ${LINKS} ...

...

Теперь я могу набрать:

rebuild.mk

и это приводит к выполнению make.

Каковы причины не использовать это на постоянной основе, кроме этого:

• Makefile привязан к одному каталогу, поэтому он не подходит для моего основного каталога bin.

Кто-нибудь когда-нибудь видел трюк, эксплуатируемый раньше?

---

Сбор некоторых комментариев и предоставление немного дополнительной справочной информации.

1. Норман Рэмси сообщает, что эта техника используется в Debian; это интересно знать. Спасибо.
2. Я согласен, что ввод 'make' более идиоматичен.
3. Однако сценарий (ранее неустановленный) состоит в том, что в моем каталоге $ HOME / bin уже есть кросс-платформенный основной make-файл, который является основным инструментом обслуживания для 500+ команд в каталоге.
4. Однако на одной конкретной машине (только) я хотел добавить make-файл для создания специального набора инструментов. Итак, эти инструменты получают специальный make-файл, который я назвал rebuild.mk для этого вопроса (у него на компьютере другое имя).
5. Я могу сохранить набрав 'make -f rebuild.mk', используя вместо этого 'rebuild.mk'.
6. Исправление положения утилиты make проблематично на разных платформах.
7. Техника #!/usr/bin/env make -f, вероятно, сработает, хотя я считаю, что официальные правила взаимодействия состоят в том, что длина строки должна быть менее 32 символов и может иметь только один аргумент команды.
8. @ dF комментирует, что техника может помешать вам передавать аргументы. Во всяком случае, это не проблема на моей машине Solaris. Все три разные версии «make», которые я тестировал (Sun, GNU, моя), получили дополнительные аргументы командной строки, которые я печатаю, включая опции («-u» в моей домашней версии) и цели «someprogram» и макросы CC = 'cc' WFLAGS = -v (чтобы использовать другой компилятор и отменить флаги предупреждения GCC, которые не понимает компилятор Sun).

Я бы не стал пропагандировать это как общую технику.

Как уже говорилось, это было в основном для моего развлечения. Я могу оставить это для этой конкретной работы; маловероятно, что я бы использовал его в распределенной работе. И если бы я это сделал, я бы поставил и применил скрипт fixin, чтобы исправить путь к интерпретатору; действительно, я сделал это уже на моей машине. Этот сценарий является реликвией из первого издания книги Camel («Программирование на Perl» Ларри Уолла).

Answer 1

Я видел этот трюк, использовавшийся до в файле debian/rules, который является частью каждого пакета Debian.

Answer 2

Одна проблема с этим для обычно распространяемых Makefiles заключается в том, что расположение make не всегда одинаково на разных платформах. Кроме того, в некоторых системах может потребоваться альтернативное имя, например gmake.

Конечно, всегда можно запустить соответствующую команду вручную, но такой подход сводит на нет всю цель создания исполняемого файла Makefile.

Answer 3

Чтобы решить проблему, когда make не всегда находится в одном и том же месте (например, в моей системе оно находится в /usr/bin), вы можете использовать

#!/usr/bin/env make -f

если вы работаете в UNIX-подобной системе.

Другая проблема заключается в том, что, используя Makefile таким способом, вы не можете переопределить переменные, например, make CFLAGS=....

Answer 4

«make» короче, чем «./Makefile», поэтому я не думаю, что вы что-то покупаете.

Answer 5

Мы можем взглянуть на это по-другому: это хорошая идея - разработать язык, интерпретатор которого ищет фиксированное имя файла, если вы его не дадите? Что если python ищет Pythonfile в отсутствие имени скрипта? ;)

Вам не нужен такой механизм, чтобы иметь соглашение, основанное на известном имени. Пример: скрипт ./configure Autoconf.

Answer 6

Для этого вы также можете использовать псевдоним оболочки.

Answer 7

Причина, по которой я бы не стал этого делать, состоит в том, что ввод "make" более идиоматичен для создания проектов на основе Makefile. Представьте, что в каждом созданном вами проекте вам нужно искать созданный кем-то файл с другим именем, а не просто набирать «make && make install».