2

正如我们所知，二进制文件依赖于 obj，而 obj 依赖于 .c 文件（假设是 C 项目）。假设我有一个 env.mk 文件。这个文件有一个类似'export NO_DISPLAY=YES'的标志。在主 Makefile 中，我有以下内容。

ifeq ($(NO_DISPLAY),YES)
CFLAGS += -D__DISPLAY_DISABLE
endif

显然，env.mk 包含在主 make 文件中。无论何时，我都会更改标志值“NO_DISPLAY”。makefile 永远不会再次重建可执行文件。但是，当删除 .o 文件时，同样可以正常工作。我了解其背后的原因，因为它取决于 .c,.h 文件。.c .h 文件没有被修改，因此 makefile 忽略重建它。但是，如果更改了 CFLAGS 值，我希望 makefile 重建代码。我该怎么做？请注意，我不想删除对象并重建它。

target_dbg: $(patsubst ./src/%.c,./obj_dbg/%.o,$(wildcard ./src/*.c)) 
    @echo "Target main rule__dbg $(NPROCS)"
    $(CC) $(patsubst ./src/%.c,./obj_dbg/%.o,$(wildcard ./src/*.c)) $(LIBS) -o gif_dbg 

./obj_dbg/%.o: ./src/%.c ./include/*.h 
    @echo "I am called first..dbg"
    @mkdir -p ./obj_dbg
    #$(CC) $(CFLAGS) -E $<
    $(CC) $(CFLAGS) $(LDFLAGS) -DDEBUG -c $< -o $@

任何帮助将不胜感激。

4

2 回答 2

2

Make simply works by examining timestamps on files. You hardly want every build artefact to depend on your Makefile (at least not while actively developing it) but if you seriously want Make to handle this dependency, you could put the CFLAGS definition in a secondary file buildflags.mk, include it from the main Makefile, and make all object files depend on buildflags.mk.

I hardly think anybody would actually do this in practice, though. There will always be situations where the only way to be sure you get a clean build is to flush everything and start over. Make sure you have good and up-to-date realclean and/or distclean targets, and make sure you remember to use them when you make fundamental changes to your build infrastructure. Having a nightly build job (or similar) which starts the build from a completely clean slate -- e.g. by checking out a new copy into a temporary directory -- is also obviously a good idea.

Alternatively, or additionally, include a copy of the build flags as a static string in each object file, so you can verify them later, perhaps using a --help option or similar.

于 2013-08-31T13:13:05.030 回答
0

每次更改. make_ 看到这个答案。-BCFLAGS

于 2014-01-27T14:15:51.460 回答