打电话在另一个目录

下面是我现在的'解决'我的问题。我认为make应该会在另一个目录中没有找到依赖规则时自动执行此操作，但我无法弄清楚为什么我会这么想。你知道更好的方法吗？打电话在另一个目录

还有另一个目录../a/它有一个Makefile来创建../a/generated.h。

.PHONY: FORCE 

FORCE: 

my.c: ../a/generated.h 
    cp --preserve=timestamps $< [email protected] 

../a/generated.h: FORCE 
    $(MAKE) -C $(dir [email protected]) $(notdir [email protected])

我有一个一般的形式，我可以使用，以避免重复每一个“外部”文件第二条规则，但正如我所说，我认为这是所有不必要的。化妆的

define REMOTE 
$(1): FORCE 
    $$(MAKE) -C $$(dir [email protected]) $$(notdir [email protected]) 
endef 

$(eval $(call REMOTE,../a/generated.h)) 
$(eval $(call REMOTE,../a/anotherGeneratedFile.h))

来源

2013-02-11 altendky

这看起来不是很好的设计。你有许多其他的目录和自己的makefile文件吗？ – Beta 2013-02-11 20:19:48

这似乎是我误解了make会自动重建包含在'Makefile'中的任何文件。 – altendky 2013-02-12 14:14:09

递归调用已知突破目标相关性，这可能是你意想不到的行为的原因的向无环图（DAG）。

针对您的问题的一种可能的解决方案可能是针对您的项目使用单个Makefile，如"Recursive Make Considered Harmful"中所建议的。否则，你可能会“提升”你的构建系统的抽象级别，并转移到像cmake这样的工具。

来源

2013-02-11 21:06:48 Massimiliano

一个很好的阅读，它会（大概）提高我对Make的使用，甚至可能解决我的根本困境。谢谢。 – altendky 2013-02-12 14:15:47

我以为make应该会自动执行此操作，当在另一个目录中找不到依赖的规则时，我无法弄清楚为什么我会这么想。

GNU Make没有这样的内置规则。查看Catalogue of Implicit Rules中的所有内置规则。

您的解决方案应该工作在中途。它没有../a/generated.h的依赖关系（因为您正在使用递归make，并且这些依赖关系仅对该目录中的makefile已知），所以它不会自动重建它。但如果它不存在，它将生成../a/generated.h。

来源

2013-02-11 22:17:04

由于它在任何时候都明确地调用其他目录中的make（注意FORCE语言），我相信它会“起作用”。只是它会在Massimiliano的链接论文中列出分离的DAG的额外开销和所有成本。 – altendky 2013-02-12 14:13:31

确实如此，除非有一个名为'FORCE'的文件。 'FORCE'应该是一个假目标。 – 2013-02-12 14:22:08

这是我对这个问题的简化不准确。纠正。 – altendky 2013-02-12 15:05:41

打电话在另一个目录

回答

相关问题