2

因此，GNU Make 的 $(wildcard) 函数在 Windows 上保持目录打开似乎存在这个问题。请参阅（未确认的）帖子“ make 正在打开一个目录”。谷歌没有提供关于该主题的太多信息。

简而言之：Makefile 在某些时候使用 $(wildcard) 函数，并保持目录打开，这通常会阻止“make clean”规则正常工作。第二次重新运行“make clean”通常可以解决它。

我在标准 DOS-Box 下使用 GNU Make 3.81 版。上面链接的帖子的作者正在使用 Cygwin。

有没有人找到解决这个问题的方法？

4

2 回答 2

2

听起来像文件描述符泄漏，好吧——对于 UNIX 上非常短暂的进程（如 make）无害，但在 Windows 上是正确的 PITA。

由于据称这是 make 中的一个错误，而不是其使用问题，因此应首先通过验证它在从最新上游版本的源代码构建时仍然存在，然后通过向GNU make提交错误报告来解决它项目（或与您有适当支持合同的任何分销商），或深入研究源并尝试自己修复它。

尝试在 Linux 上重现不会有什么坏处——在这里检查文件描述符泄漏要容易得多，因为人们可以只看/proc/self/fd（或者，对于 make 的孩子，/proc/$PPID/fd）不属于的东西。

于 2008-10-20T23:42:36.937 回答
0

我确实找到了解决该问题的方法，至少可以让我安心工作。

问题是该$(wildcard)函数用于收集源文件。然而，我的干净规则只删除了一个目录 - 不需要收集。所以我基本上把Makefile中需要收集源文件的部分放在一个条件语句中：

# The clean rule is always parsed
clean:
    rm -rf $(OUTPUT_DIRECTORY)

# The compile rule is only interpreted if we did not invoke 'make clean'. We
# can test the value of $(MAKECMDGOALS) for that:
ifeq ($(filter $(MAKECMDGOALS),clean),)

SOURCE_FILES := $(wildcard ...)

compile:
    g++ $(SOURCE_FILES) ...

endif
于 2008-12-23T05:31:34.940 回答