我知道编程语言有很多 linter，例如 pep8 用于 python，但我从未遇到过用于 makefile 的 linter。 makefiles 有这样的 linter 吗？
还有其他方法可以在不实际运行的情况下以编程方式检测 makefile 中的错误或问题吗？
随着我逐渐使用 makefile，它变得越来越复杂和冗长，对我来说，有一个 linter 让 makefile 更具可读性是有意义的。
【问题讨论】：
唯一类似于lint 行为的是命令行选项--warn-undefined-variables
【讨论】：
我也不知道在哪里可以找到 make file lint（网络搜索“make file lint”让我找到了这里），但这里有一个不完整的用于实现 make file lint 实用程序的简单想法片段列表......
空格是可读性的一个方面，因为制表符和空格在 make 文件中具有不同的语义。 Emacs makefile-mode 默认情况下会在您尝试使用间隔很短的制表符保存 make 文件时警告您“可疑”行。也许以批处理模式运行 emacs 并从该模式调用解析和验证功能是可行的。如果有人开始实现这样的 make 文件 lint 实用程序，那么检查 emacs lisp 模式可能会很有趣。
关于检查正确性，@Mark Galeck 在他的回答中已经提到了--warn-undefined-variables。问题是未定义但标准化的变量有很多输出。为了改进这个想法，可以添加一个简单的包装器来过滤掉有关这些变量的消息，以便发现真正的拼写错误。在这种情况下，make 可以使用选项--just-print（又名-n 或--dry-run）运行，以便不运行实际命令来构建目标。
使用 --just-print 选项运行 make 时执行任何更改不是一个好主意。对 $(shell ...) 函数调用进行 grep 并尝试确保其中没有任何更改会很有用。我们可以检查的第一次迭代：$(shell pwd) 和其他一些常见的非破坏性用途是可以的，其他任何东西都应该引发手动检查的警告。
我们可以用 grep 查找 $ 而不是 (（可能类似于 [$][^$(][[:space:]] 用 POSIX 正则表达式表示）来捕获像 $VARIABLE 这样解析为 $(V)ARIABLE 的情况，可能不是作者的本意，也不是很好的风格。
make 文件的问题在于它们非常复杂，包含所有嵌套结构，如 $(shell)、$(call)、$(eval) 和规则评估；结果可以从环境或命令行的输入或调用 make 调用中改变；还有许多隐含的规则或其他定义使任何更深层次的语义分析成为问题。我认为包罗万象的 make lint 实用程序是不可行的（除了可能内置在 make 实用程序本身中），但某些编码指南和启发式检查已经证明确实有用。
【讨论】：
【讨论】：