On Tue, 4 May 2010 12:22:10 -0500, Matthew Knepley <knepley at gmail.com> wrote: > It looks like tup only has a Linux daemon, so it would run the same as make > everywhere else. That does not seem like a strong enough case to use it. Why > not just write the same thing in portable Python? We do need to run > everywhere.
Of course tup couldn't be the only backend, but it would be a fast one where available (which includes Mac and Solaris). Contrary to popular belief, make itself is not slow compared to almost any alternative (except tup), *recursive* make is slow. A do-nothing build (basically just dependency analysis) of PETSc with non-recursive make takes well under a second. You can certainly do the dependency analysis in Python but I haven't yet seen a Python build system that's actually better than make *at doing what make was made for* (despite many attempts). Note that correct dependency analysis requires parsing includes (e.g. gcc -M and various more and less ad-hoc scripts), make has limited ability to keep the dependency output from these files appropriately synced in the presence of makefile changes and source changes (it has to choose between pessimal and incorrect behavior). The point of systems like tup is that they maintain these dependencies in a form (SQLite) where optimal and fast analysis is feasible. You could reproduce this analysis in Python, but I don't think it's trivial to do correctly or performantly. Note that one of tup's features is to not stat() the whole source tree, this requires something like inotify which is the reason it doesn't automatically work everywhere. It might be easy enough to have a fallback that just stats the whole thing, but this would have about the same performance as make. Jed
