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.
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".
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...
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.
(Not bashing on tup at all here, I just prefer that "the opposition" is represented fairly in comparisons.)