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

[Matthew Knepley]

On Tue, May 4, 2010 at 12:50 PM, Jed Brown <jed at 59a2.org> wrote:

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


1) Yep, I agree. However, it has been my experience that Linux projects do
    not give two shits about Windows users. We created builder.py
specifically
    for the Windows build. I do not trust any of these guys to care about
the
    things we have to care about.

2) http://www.alittletooquiet.net/software/inotifyx/

    http://trac.dbzteam.org/pyinotify

    I am leaning towards the first.

    Matt


> Jed
>



-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100504/7e64f810/attachment.html>