OSDev.org

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

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

OK, it is now painfully obvious that my makefiles were set up wrong to begin with. Can you please post an example? I think it will help more than just me.

It's all in the wiki.

OK, so, separate step to build the .d files and having to run the output through sed to prepend the actual output directory....

You know, I went and looked at the history to see where I might have missed it. No fair that you updated it less than 2 weeks ago!!!

Seriously, though, I never saw this wiki. I spent all my time reading the Hard Build System, which of course had an external link to the GNU Make manual but no link to this wiki. I never thought to search for "makefile".

eryjus wrote:OK, so, separate step to build the .d files and having to run the output through sed to prepend the actual output directory....

Errr.... what? As I said, the .d files are created by GCC, by virtue of the -MMD -MP options.

eryjus wrote:You know, I went and looked at the history to see where I might have missed it. No fair that you updated it less than 2 weeks ago!!!

There has not been a significant edit to that wiki page for years. I fixed an outdated link... the part about the dependency handling was in there since, uh, 2010?

So, I realized where my mistakes came from. I thought it good to share what I did wrong.

I was using Peter Miller's paper linked from the Hard Build System wiki. In particular, section 5.4 outlines a dependency configuration that is inferior to what is outlined in the Makefile wiki.

At any rate, I did add a comment to the wiki as a call-out. Hopefully, others can learn before they make the same mistakes I did.

Solar wrote:There has not been a significant edit to that wiki page for years. I fixed an outdated link... the part about the dependency handling was in there since, uh, 2010?

It still make me laugh!

I've been using Tup for over 6 months for OS development. It's a superb and extremely capable tool, with many minor issues that let it down. The Tup language is not very expressive, it doesn't integrate as well into the rest of the unix environment as make does, and it's lack of recursive globbing is sometimes a problem. Nevertheless, it's definitely worth trying.

EDIT: I'll add now that I've finally switched to Make. Tup is very, very good. But nothing beats Make for versatility and POSIX integration.