Re: [9fans] Barrelfish

[Jason Catena <jason.catena@gmail.com>]

>> One thing complicating this is that make and its common
>> variants aren't smart enough to handle the case where
>> version control systems regress a file and present an
>> earlier date not newer than the derived object.
>
> See cons/scons.

Thanks for the suggestion.  In this project someone actually made that
same suggestion, but rudely—basically insulting the very thought that
someone would be stupid enough to base a build system for commercial
software on make. (Right in line with gnu bias, I thought at the time:
forceful and disrespectful is no way to make change happen, even if
your target was previously inclined your way.)

In any event it's not compatible with the speedup tool we selected.
Which brings up the unnecessary additional complexity of embedding a
dependency analysis and shell-command tool in a general language.  Am
I expected to complicate my project management tool with python, just
to get it to rebuild if a file dependency's date changes at all,
rather than only if the file dependency has a newer date?  What's
wrong with a little language these days?  I don't think python needs a
file system dependency analysis engine any more than make needs a full
language around it.

I'd rather store the date of every leaf file on the dependency tree,
and in the next build delete any objects derived from a file with a
different date.  At least that's a consistent programming metaphor.

Even the academic project managers out there don't try to mind-merge a
general language.  For example, Odin complicates make's syntax and
execution, almost introducing a type system for targets.  This makes
it very tricky to generate and edit makefiles dynamically in an
existing system, since (IIRC) you have to reload the whole ruleset if
you change something.

> Dave Eckhardt

Jason Catena