是否有充分的理由不利用“#!/bin/make -f”？ 在 makefile 的顶部给出可执行的 makefile？
主要是为了娱乐，我在 $HOME/bin 目录中创建了一个名为 rebuild.mk 的 makefile，并使其可执行，第一个文件行如下：
#!/bin/make -f
#
# Comments on what the makefile is for
...
all: ${SCRIPTS} ${LINKS} ...
...
I now can type:
rebuild.mk
这会导致 make 执行。
除了这个之外，不永久利用它的原因还有哪些：
- makefile 绑定到单个目录，因此它确实不适合我的主
bin目录。
有人曾经见过这个技巧被利用过吗？
收集一些评论，并提供更多背景信息。
- Norman Ramsey 报告称该技术已在 Debian 中使用； 这很有趣。 谢谢。
- 我同意输入“make”更惯用。
- 然而，场景（之前未说明）是我的 $HOME/bin 目录中已经有一个跨平台的主 makefile，它是该目录中 500 多个命令的主要维护工具。
- 然而，在一台特定的机器上（仅），我想添加一个 makefile 来构建一组特殊的工具。 因此，这些工具会获得一个特殊的 makefile，针对这个问题我将其称为
rebuild.mk（它在我的机器上有另一个名称）。 - 我确实可以通过使用“
rebuild.mk”来节省输入“make -frebuild.mk”。 - 跨平台修复
make实用程序的位置是有问题的。 #!/usr/bin/env make -f技术可能会起作用，尽管我相信官方的参与规则是该行必须少于 32 个字符，并且可能只有一个参数命令。- @dF 评论说该技术可能会阻止您传递参数来 make。 无论如何，这在我的 Solaris 机器上不是问题。 我测试的三个不同版本的“make”（Sun、GNU、我的）都获得了我输入的额外命令行参数，包括选项（我的自制版本上的“-u”）和目标“someprogram”和宏 CC ='cc' WFLAGS=-v（使用不同的编译器并取消 Sun 编译器无法理解的 GCC 警告标志）。
我不会提倡将此作为通用技术。
如前所述，这主要是为了我的娱乐。 我可能会为了这个特定的工作而保留它； 我不太可能在分布式工作中使用它。 如果我这样做了，我会提供并应用一个“fixin”脚本来修复解释器的路径名； 事实上，我已经在我的机器上这样做了。 该脚本是 Camel 书第一版的遗物（Larry Wall 的“Programming Perl”）。
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} ...
...
I can now type:
rebuild.mk
and this causes make to execute.
What are the reasons for not exploiting this on a permanent basis, other than this:
- The makefile is tied to a single directory, so it really isn't appropriate in my main
bindirectory.
Has anyone ever seen the trick exploited before?
Collecting some comments, and providing a bit more background information.
- Norman Ramsey reports that this technique is used in Debian; that is interesting to know. Thank you.
- I agree that typing 'make' is more idiomatic.
- 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.
- 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.mkfor this question (it has another name on my machine). - I do get to save typing '
make -f rebuild.mk' by using 'rebuild.mk' instead. - Fixing the position of the
makeutility is problematic across platforms. - The
#!/usr/bin/env make -ftechnique 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. - @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).
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).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们可以用另一种方式来看待这个问题：设计一种语言，如果你不给它一个固定的文件名，它的解释器就会寻找固定的文件名，这是一个好主意吗？ 如果
python在缺少脚本名称的情况下查找Pythonfile会怎样？ ;)您不需要这样的机制来建立基于已知名称的约定。 示例：Autoconf 的
./configure脚本。We can look at this another way: is it a good idea to design a language whose interpreter looks for a fixed filename if you don't give it one? What if
pythonlooked forPythonfilein the absence of a script name? ;)You don't need such a mechanism in order to have a convention based around a known name. Example: Autoconf's
./configurescript.对于一般可分发的 Makefile 来说，一个问题是
make的位置在不同平台上并不总是一致。 此外，某些系统可能需要一个备用名称，例如gmake。当然，人们总是可以手动运行适当的命令，但是这种方式违背了使 Makefile 可执行的整个目的。
One problem with this for generally distributable Makefiles is that the location of
makeis not always consistent across platforms. Also, some systems might require an alternate name likegmake.Of course one can always run the appropriate command manually, but this sort of defeats the whole purpose of making the Makefile executable.
我之前在每个 Debian 软件包的
debian/rules文件中见过这个技巧。I've seen this trick used before in the
debian/rulesfile that is part of every Debian package.为了解决
make并不总是位于同一位置的问题（例如在我的系统上，它位于/usr/bin中），如果您位于类UNIX系统。
另一个问题是，通过这种方式使用 Makefile，您无法通过执行
make CFLAGS=...等操作来覆盖变量。To address the problem of
makenot always being in the same place (on my system for example it's in/usr/bin), you could useif you're on a UNIX-like system.
Another problem is that by using the Makefile this way you cannot override variables, by doing, for example
make CFLAGS=....“make”比“./Makefile”短，所以我认为您没有购买任何东西。
"make" is shorter than "./Makefile", so I don't think you're buying anything.
我不会这样做的原因是，键入“make”对于构建基于 Makefile 的项目更为惯用。 想象一下，如果您构建的每个项目都必须搜索某人创建的不同名称的 makefile，而不是仅仅键入“make && make install”。
The reason I would not do this is that typing "make" is more idiomatic to building Makefile based projects. Imagine if every project you built you had to search for the differently named makefile someone created instead of just typing "make && make install".
您也可以为此使用 shell 别名。
You could use a shell alias for this too.