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:
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.
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
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.