On Tue, May 4, 2010 at 12:50 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 4 May 2010 12:22:10 -0500, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> It looks like tup only has a Linux daemon, so it would run the same as make<br>
> everywhere else. That does not seem like a strong enough case to use it. Why<br>
> not just write the same thing in portable Python? We do need to run<br>
> everywhere.<br>
<br>
</div>Of course tup couldn't be the only backend, but it would be a fast one<br>
where available (which includes Mac and Solaris).  Contrary to popular<br>
belief, make itself is not slow compared to almost any alternative<br>
(except tup), *recursive* make is slow.  A do-nothing build (basically<br>
just dependency analysis) of PETSc with non-recursive make takes well<br>
under a second.<br>
<br>
You can certainly do the dependency analysis in Python but I haven't yet<br>
seen a Python build system that's actually better than make *at doing<br>
what make was made for* (despite many attempts).  Note that correct<br>
dependency analysis requires parsing includes (e.g. gcc -M and various<br>
more and less ad-hoc scripts), make has limited ability to keep the<br>
dependency output from these files appropriately synced in the presence<br>
of makefile changes and source changes (it has to choose between<br>
pessimal and incorrect behavior).<br>
<br>
The point of systems like tup is that they maintain these dependencies<br>
in a form (SQLite) where optimal and fast analysis is feasible.  You<br>
could reproduce this analysis in Python, but I don't think it's trivial<br>
to do correctly or performantly.  Note that one of tup's features is to<br>
not stat() the whole source tree, this requires something like inotify<br>
which is the reason it doesn't automatically work everywhere.  It might<br>
be easy enough to have a fallback that just stats the whole thing, but<br>
this would have about the same performance as make.</blockquote><div><br></div><div>1) Yep, I agree. However, it has been my experience that Linux projects do</div><div>    not give two shits about Windows users. We created builder.py specifically</div>
<div>    for the Windows build. I do not trust any of these guys to care about the</div><div>    things we have to care about.</div><div><br></div><div>2) <a href="http://www.alittletooquiet.net/software/inotifyx/">http://www.alittletooquiet.net/software/inotifyx/</a></div>
<div><br></div><div>    <a href="http://trac.dbzteam.org/pyinotify">http://trac.dbzteam.org/pyinotify</a></div><div> </div><div>    I am leaning towards the first.</div><div> </div><div>    Matt</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Jed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>