There are a couple of CMake-generated files at the top level of the binary directory, most prominently the CMakeCache.txt holding all the stored values (so CMake doesn't have to re-run all the tests e.g. regarding system libraries), and of course the build files (Makefile, MSVC solution, ...). I am not sure what you refer to as "the test image".eryjus wrote:Now, I can barely spell 'CMake', but it sounds like it could have a similar situation where the build files would "clutter" up the test image depending on how it was set up.
That's the case for the Makefile as well: The (generated) .d file lists itself as a dependency for the .o file. Again, on first build you need to run the rule anyway, and on subsequent builds the (included) .d file handles the dependency.Solar wrote:I'm sure there are many other ways to do this other than what I had set up, but I also had to make sure that the .o file was dependent on the .d file...
(Not bashing on tup at all here, I just prefer that "the opposition" is represented fairly in comparisons.)