I did a lot of work on the linux kernel build system (quite a while ago), and somehow the gittup comparison doesn't appear right.<br><br>I just counted *.[hc] in linux 2.6.18 (way old, but anyway), that's about 21,000 files, and running make on an unchanged, previously built, tree takes at most a few seconds. That's a project which is way larger than petsc, and make does a "good enough" job there. I'll also dispute that recursive make is necessarily wrong, it's quite possible to do things recursively but correct, even though it's not optimal for performance (but that is not really an issue in a petsc-sized project). Linux kernel relies on gnu make features, so it's not really portable, but that's mostly related to the very high configurability needs.<br>
<br>In my opinion, you have to take into account a number of aspects when doing software. Undoubtedly, make has its flaws, and python is a much nicer language, and probably could do the job better. But the flipside is that everyone knows make (well, I wish, but anyway), but no outsider is prepared to deal with the intricacies of a python based build which is custom made for petsc. I think this is important, I don't want to learn a new build system, configure, whatever for every project out there, I'd prefer existing systems to be used if they're good enough. (OTOH, I wouldn't consider petsc's current build good enough, I hate the fact that intermediate files are being removed and rebuilding takes forever even if only one file was changed)<br>
<br>I just wanted to put this out there. It's not only about your own perfect tool, it's also about others who you want to be able to work with the code without spending a month learning the tools.<br><br>I actually find autoconf/automake fairly usable. They're not pretty, but they're used in so many projects, I got used to them, so I actually prefer them over the custom configure.py in petsc, even though that's technically a lot prettier. Unfortunately, I don't think autotools are usable on windows, so cmake or something maybe an alternative to look into. Using one of the popular systems certainly would have upsides, IMO.<br>
<br>--Kai<br><br><br><div class="gmail_quote">On Tue, May 4, 2010 at 12:51 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, 4 May 2010 11:37:14 -0500, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> I see. Yes, it currently uses the makefile organization. This is the<br>
> kind of metadata that Barry would like in a DB rather than in<br>
> makefiles.<br>
<br>
</div>It would be easy to convert between being spread out in the makefiles<br>
and being held in some central location.  For instance, something like<br>
builder.py, run at the end of configuration time, could instead of<br>
building the project, write a single tupfile [1] for all of PETSc, and<br>
then we could rejoice with fast correct builds, even after<br>
reconfiguring.<br>
<br>
I think the metadata itself belongs with the implementations (more or<br>
less where it is currently) unless we are actually working with an<br>
image-based system (which does not look likely in the near future).<br>
<br>
Jed<br>
<br>
[1] For those who not in the know: <a href="http://gittup.org/tup/make_vs_tup.html" target="_blank">http://gittup.org/tup/make_vs_tup.html</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245E<br>phone:  +1-603-862-2912<br>
fax: +1-603-862-2771<br><br>