>> 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.
The non-Plan 9 world suffers from several structural problems which have undermined make's original model. A big one is file systems with routine large clock skew, and another is the N-layers-deep (for large N) nature (build libraries to build tools to build libraries to build applications) which is considered reasonable, or at least unavoidable. Combining that last one with the absence of namespaces makes the problem truly painful in ways which (I think) stretch it outside of the make model. It's possible to "make it work" with enough thrust, but I think people who have done that once and then tried cons/scons think the change is worthwhile. Cons was written by somebody who was in charge of "strap enough thrust onto make" twice and he wrote it to address exactly the problems he saw so he could skip past that part at startup #3. > 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? Cons and scons get you more than that. Few make systems notice when your compiler has changed out from under you. With gcc's drift rate that could be particularly valuable :-) > What's wrong with a little language these days? Personally I don't find make as typically "augmented" by m4 plus 3,000-line shell scripts to qualify as a "little language". But YMMV and this isn't a make-vs-cons list. Dave Eckhardt
