Digging deeper into the other files that make
reads, in build/CMakeFiles/bar.dir/build.make
, I see the following at the end of that file:
CMakeFiles/bar.dir/depend: version_autogen.h
cd /Users/craig/Projects/gen_header/build && $(CMAKE_COMMAND) -E cmake_depends "Unix Makefiles" /Users/craig/Projects/gen_header /Users/craig/Projects/gen_header /Users/craig/Projects/gen_header/build /Users/craig/Projects/gen_header/build /Users/craig/Projects/gen_header/build/CMakeFiles/bar.dir/DependInfo.cmake --color=$(COLOR)
.PHONY : CMakeFiles/bar.dir/depend
Earlier near the top of that same file is this:
# Include any dependencies generated for this target.
include CMakeFiles/bar.dir/depend.make
Initially after first running CMake, the file at CMakeFiles/bar.dir/depend.make
doesn’t hold anything interesting. If you were to ask to build just version.o
at this point, it would indeed fail because the Makefiles don’t set up any rules that make the compilation step depend on regenerating the dependencies first. This is probably a bug in CMake’s Makefile generation (@marc.chevrier you may be interested in this). If you were to build the bar
target rather than version.o
though, it does seem to invoke the header generation first. After you’ve done a build once, the file at CMakeFiles/bar.dir/depend.make
will now hold a rule which enforces the missing constraint:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.19
CMakeFiles/bar.dir/version.c.o: ../version.c
CMakeFiles/bar.dir/version.c.o: version_autogen.h
So yes, there is a small window of opportunity for specific use cases before the first build at least, but after that it is probably enforced. Maybe @marc.chevrier has more insight on this, he’s been working on the dependency handling lately.