GNU make的-j选项
自从我了解了-j之后，我就一直在随意地使用-j8。前几天，我正在编译一个atlas安装，make失败了。最终，我发现它是按顺序制造的--当我回到单线程make时，它工作得很好。这让我很紧张。在编写自己的make文件时，为了避免使用make -j做一些意想不到的事情，我需要注意哪些条件？
回答 5
Stack Overflow用户
发布于 2009-10-14 04:38:11
我认为make -j会遵守您在Makefile中指定的依赖关系；例如，如果您指定objA依赖于objB和objC，那么在objB和objC完成之前，make将不会开始在objA上工作。
很可能您的Makefile没有严格指定必要的操作顺序，幸运的是它正好在单线程的情况下为您工作。
Stack Overflow用户
发布于 2009-10-14 04:45:49
简而言之--确保你的依赖是正确和完整的。
如果您使用单线程make，那么您可能会盲目地忽略目标之间的隐式依赖关系。当使用并行make时，你不能依赖于隐式依赖。它们都应该被明确地表达出来。这可能是最常见的陷阱。特别是在使用.phony目标作为依赖项时。
对于并行制作的一些问题，This link是一个很好的入门读物。
Stack Overflow用户
发布于 2010-04-11 01:42:25
这是我开始使用并行构建时遇到的一个问题的示例。我有一个叫做"fresh“的目标，我用它从头开始重建目标(一个"fresh”构建)。在过去，我通过简单地指示“清理”然后“构建”作为依赖项来编码“刷新”目标。
build: ## builds the default target
clean: ## removes generated files
fresh: clean build ## works for -j1 but fails for -j2在我开始使用并行构建之前，它工作得很好，但对于并行构建，它试图同时进行“干净”和“构建”。因此，我更改了"fresh“的定义，如下所示，以保证操作的正确顺序。
fresh:
$(MAKE) clean
$(MAKE) build从根本上说，这只是正确指定依赖项的问题。诀窍是并行构建比单线程构建对此更严格。我的示例演示了给定目标的依赖项列表不一定指示执行顺序。
https://stackoverflow.com/questions/1564195
复制相似问题