我有一个生成文件，然后调用另一个生成文件。因为这个makefile调用了更多的makefile来完成这项工作，所以它并没有真正改变。因此，它一直认为该项目是建立和最新的。
dnetdev11 ~ # make
make: `release' is up to date.
如何强制makefile重新构建目标?
clean = $(MAKE) -f ~/xxx/xxx_compile.workspace.mak clean
build = svn up ~/xxx \
$(clean) \
~/cbp2mak/cbp2mak -C ~/xxx ~/xxx/xxx_compile.workspace \
$(MAKE) -f ~/xxx/xxx_compile.workspace.mak $(1) \
release:
$(build )
debug:
$(build DEBUG=1)
clean:
$(clean)
install:
cp ~/xxx/source/xxx_utility/release/xxx_util /usr/local/bin
cp ~/xxx/source/xxx_utility/release/xxxcore.so /usr/local/lib
注:为保护无辜，删除姓名
最终固定版本:
clean = $(MAKE) -f xxx_compile.workspace.mak clean;
build = svn up; \
$(clean) \
./cbp2mak/cbp2mak -C . xxx_compile.workspace; \
$(MAKE) -f xxx_compile.workspace.mak $(1); \
.PHONY: release debug clean install
release:
$(call build,)
debug:
$(call build,DEBUG=1)
clean:
$(clean)
install:
cp ./source/xxx_utillity/release/xxx_util /usr/bin
cp ./dlls/Release/xxxcore.so /usr/lib
根据米勒的递归使认为有害，你应该避免调用$(Make)!在您所展示的情况中，它是无害的，因为这不是一个真正的makefile，只是一个包装器脚本，它也可能是用Shell编写的。但是你说你在更深层次的递归中继续这样做，所以你可能遇到了那篇令人大开眼界的文章中所显示的问题。
当然，使用GNU的make是很麻烦的。尽管他们意识到了这个问题，但这是他们记录在案的做事方式。
OTOH，创建makepp就是为了解决这个问题。您可以在每个目录级别上编写makefile文件，但它们都汇集到项目的完整视图中。
But legacy makefiles are written recursively. So there's a workaround where $(MAKE) does nothing but channel the subrequests back to the main makepp process. Only if you do redundant or, worse, contradictory things between your submakes, you must request --traditional-recursive-make (which of course breaks this advantage of makepp). I don't know your other makefiles, but if they're cleanly written, with makepp necessary rebuilds should happen automatically, without the need for any hacks suggested here by others.
一个曾经在Sun手册中记录的make技巧是使用一个(不存在的)目标'. force '。你可以创建一个文件，force。Mk，它包含:
.FORCE:
$(FORCE_DEPS): .FORCE
然后，假设你现有的makefile被称为makefile，你可以运行:
make FORCE_DEPS=release -f force.mk -f makefile release
由于. force不存在，依赖于它的任何东西都将过时并重新构建。
所有这些都适用于任何版本的make;在Linux上，您有GNU Make，因此可以像前面讨论的那样使用. phony目标。
同样值得考虑的是，为什么make认为release是最新的。这可能是因为你在执行的命令中有一个触摸释放命令;这可能是因为存在一个名为“release”的文件或目录，它没有依赖关系，所以是最新的。还有真正的原因…
根据米勒的递归使认为有害，你应该避免调用$(Make)!在您所展示的情况中，它是无害的，因为这不是一个真正的makefile，只是一个包装器脚本，它也可能是用Shell编写的。但是你说你在更深层次的递归中继续这样做，所以你可能遇到了那篇令人大开眼界的文章中所显示的问题。
当然，使用GNU的make是很麻烦的。尽管他们意识到了这个问题，但这是他们记录在案的做事方式。
OTOH，创建makepp就是为了解决这个问题。您可以在每个目录级别上编写makefile文件，但它们都汇集到项目的完整视图中。
But legacy makefiles are written recursively. So there's a workaround where $(MAKE) does nothing but channel the subrequests back to the main makepp process. Only if you do redundant or, worse, contradictory things between your submakes, you must request --traditional-recursive-make (which of course breaks this advantage of makepp). I don't know your other makefiles, but if they're cleanly written, with makepp necessary rebuilds should happen automatically, without the need for any hacks suggested here by others.
