我有一个生成文件,然后调用另一个生成文件。因为这个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

当前回答

这实际上取决于目标是什么。如果它是一个伪目标(即目标与文件无关),你应该将它声明为. phony。

然而,如果目标不是伪目标,而只是出于某种原因想要重新构建它(例如当你使用__TIME__预处理宏时),你应该使用回答中描述的FORCE方案。

其他回答

还有人建议使用. phony,这是绝对正确的。. phony应该用于任何输入和输出之间的日期比较无效的规则。由于表单output: input没有任何目标,所以应该对所有目标都使用.PHONY !

尽管如此,您可能应该在makefile的顶部为各种文件名定义一些变量,并定义真正的make规则,这些规则同时具有输入和输出部分,这样您就可以利用make的好处,即您只编译需要复制的东西!

编辑:新增示例。未经测试,但你就是这么做的。假的

.PHONY: clean    
clean:
    $(clean)

根据米勒的递归使认为有害,你应该避免调用$(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.

我试过了,对我很有效

将这些行添加到Makefile中

clean:
    rm *.o output

new: clean
    $(MAKE)     #use variable $(MAKE) instead of make to get recursive make calls

保存,然后调用

make new 

它会重新编译所有东西

发生了什么事?

1)“新”就是干净。 'clean' do 'rm'删除所有扩展名为'.o'的目标文件。

2)'new'调用'make'。 'make'看到没有'。O '文件,因此它创建了所有的'。o '了。然后链接器将所有.o文件链接到一个可执行输出中

祝你好运

make的-B开关,其长形式为——always-make,告诉make忽略时间戳并使指定的目标。这可能会违背使用make的目的,但它可能正是您所需要的。

你可以宣布一个或多个目标是假的。

A phony target is one that is not really the name of a file; rather it is just a name for a recipe to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance. ... A phony target should not be a prerequisite of a real target file; if it is, its recipe will be run every time make goes to update that file. As long as a phony target is never a prerequisite of a real target, the phony target recipe will be executed only when the phony target is a specified goal