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