是否有充分的理由不利用makefile顶部的'#！/bin/make -f'来提供可执行的makefile? [英] Are there good reasons not to exploit '#!/bin/make -f' at the top of a makefile to give an executable makefile?

问题描述

主要出于娱乐目的，我在$HOME/bin目录中创建了一个makefile，名为rebuild.mk，并将其设置为可执行文件，并且文件的第一行显示为:

Mostly for my amusement, I created a makefile in my $HOME/bin directory called rebuild.mk, and made it executable, and the first lines of the file read:

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

...

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

...

我现在可以输入:

rebuild.mk

这将导致make执行.

除此以外，不永久利用此原因的原因是什么?

What are the reasons for not exploiting this on a permanent basis, other than this:

• makefile绑定到一个目录，因此在我的主bin目录中确实不合适.

• The makefile is tied to a single directory, so it really isn't appropriate in my main bin directory.

有没有人看过以前利用过的技巧?

Has anyone ever seen the trick exploited before?

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

Collecting some comments, and providing a bit more background information.

1. 诺曼·拉姆齐(Norman Ramsey)报告说，该技术已在Debian中使用；这很有趣.谢谢.
2. 我同意键入"make"会比较习惯.
3. 但是，这种情况(以前未声明)是我的$ HOME/bin目录中已经有一个跨平台的主makefile，它是该目录中500多个命令的主要维护工具.
4. 但是，在一台特定的机器上(仅)，我想添加一个makefile来构建一组特殊的工具.因此，这些工具会得到一个特殊的生成文件，我对此问题称为rebuild.mk(在我的机器上有另一个名称).
5. 我确实使用'rebuild.mk'来保存键入'make -f rebuild.mk'.
6. 在各个平台上固定make实用程序的位置都是有问题的.
7. #!/usr/bin/env make -f技术很可能有效，尽管我相信正式的约定规则是该行必须少于32个字符，并且该命令只能有一个参数.
8. @dF注释，该技术可能会阻止您传递要进行的参数.无论如何，这在我的Solaris机器上都不是问题.我测试的三个不同版本的"make"(Sun，GNU，我的)都获得了我键入的额外命令行参数，包括选项(我的自制版本中的"-u")，并针对"someprogram"和宏CC ='cc'WFLAGS = -v(以使用其他编译器并取消Sun编译器无法理解的GCC警告标志).

1. Norman Ramsey reports that this technique is used in Debian; that is interesting to know. Thank you.
2. I agree that typing 'make' is more idiomatic.
3. However, the scenario (previously unstated) is that my $HOME/bin directory already has a cross-platform main makefile in it that is the primary maintenance tool for the 500+ commands in the directory.
4. However, on one particular machine (only), I wanted to add a makefile for building a special set of tools. So, those tools get a special makefile, which I called rebuild.mk for this question (it has another name on my machine).
5. I do get to save typing 'make -f rebuild.mk' by using 'rebuild.mk' instead.
6. Fixing the position of the make utility is problematic across platforms.
7. The #!/usr/bin/env make -f technique is likely to work, though I believe the official rules of engagement are that the line must be less than 32 characters and may only have one argument to the command.
8. @dF comments that the technique might prevent you passing arguments to make. That is not a problem on my Solaris machine, at any rate. The three different versions of 'make' I tested (Sun, GNU, mine) all got the extra command line arguments that I type, including options ('-u' on my home-brew version) and targets 'someprogram' and macros CC='cc' WFLAGS=-v (to use a different compiler and cancel the GCC warning flags which the Sun compiler does not understand).

我不主张将此作为通用技术.

如上所述，这主要是出于娱乐目的.我可以保留这份工作.我不太可能在分布式工作中使用它.如果这样做了，我将提供并应用一个'fixin'脚本来修复解释器的路径名.确实，我已经在我的机器上做到了.该脚本是骆驼第一版(Larry Wall的"Programming Perl")中的遗物.

I would not advocate this as a general technique.

As stated, it was mostly for my amusement. I may keep it for this particular job; it is most unlikely that I'd use it in distributed work. And if I did, I'd supply and apply a 'fixin' script to fix the pathname of the interpreter; indeed, I did that already on my machine. That script is a relic from the first edition of the Camel book ('Programming Perl' by Larry Wall).

推荐答案

通常可分发的Makefile的一个问题是make的位置在各个平台之间并不总是一致的.另外，某些系统可能需要一个备用名称，例如gmake.

One problem with this for generally distributable Makefiles is that the location of make is not always consistent across platforms. Also, some systems might require an alternate name like gmake.

当然，总是可以手动运行适当的命令，但是这种做法破坏了使Makefile可执行的全部目的.

Of course one can always run the appropriate command manually, but this sort of defeats the whole purpose of making the Makefile executable.

这篇关于是否有充分的理由不利用makefile顶部的'#！/bin/make -f'来提供可执行的makefile?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！