是否有充分的理由不利用makefile顶部的'#!/ bin/make -f'来提供可执行的makefile？

主要是为了娱乐,我makefile在我的$HOME/bin目录中创建了一个名为rebuild.mk,并使其可执行,并且文件的第一行读取:

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

...

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

...

我现在可以输入:

rebuild.mk

这导致make执行.

除了这个之外,没有永久性地利用这个的原因是什么:

makefile绑定到一个目录,所以它在我的主bin目录中确实不合适.

有没有人见过以前被利用过的伎俩？

收集一些评论,并提供更多的背景信息.

诺曼拉姆齐报告说这种技术用于Debian; 这很有趣.谢谢.

我同意输入'make'更加惯用.

但是,该场景(以前未说明)是我的$ HOME/bin目录中已经有一个跨平台的主makefile,它是目录中500+命令的主要维护工具.

但是,在一台特定的机器上(仅),我想添加一个makefile来构建一组特殊的工具.所以,这些工具得到一个特殊的makefile,我打电话rebuild.mk给这个问题(它在我的机器上有另一个名字).

我确实可以make -f rebuild.mk使用' rebuild.mk' 保存输入' ' .

修复make实用程序的位置是跨平台的问题.

该#!/usr/bin/env make -f技术很可能会奏效,但我认为正式的参与规则是该行必须少于32个字符,并且该命令可能只有一个参数.

@dF评论该技术可能会阻止您将参数传递给make.无论如何,这对我的Solaris机器来说不是问题.我测试的三个不同版本的'make'(Sun,GNU,我的)都得到了我输入的额外命令行参数,包括选项(我的家酿版本上的'-u')和目标'someprogram'和宏CC ='cc'WFLAGS = -v(使用不同的编译器并取消Sun编译器无法理解的GCC警告标志).

我不会主张这是一种通用技术.

如上所述,这主要是为了我的娱乐.我可以为这个特殊的工作保留它; 我不太可能在分布式工作中使用它.如果我这样做,我会提供并应用一个' fixin'脚本来修复解释器的路径名; 的确,我已经在我的机器上做过了.这个剧本是第一版骆驼书(拉里·沃尔的"编程Perl")的遗物.

对于通常可分发的Makefile,这个问题的一个问题make是跨平台的位置并不总是一致的.此外,某些系统可能需要一个替代名称,如gmake.

当然,人们总是可以手动运行适当的命令,但这种方法会破坏使Makefile可执行的全部目的.

我已经在文件中看到过这个技巧debian/rules,它是每个Debian软件包的一部分.