[petsc-dev] reminder never use #include "mylocalinclude.h" in PETSc source

[Jed Brown]

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