On Tue, May 4, 2010 at 1:08 PM, Kai Germaschewski <kai.germaschewski at unh.edu > wrote:
> 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. > > 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. > > 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) > > 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. > > 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. > Well, I will take that criticism from people who actually do something to the configure. I try to remind myself that for systems where I actually change something, getting inside the tool matters, otherwise let them do it their way. We had an entire Autotools build in 2002. It was a giant, unmaintainable piece of shit. That is why we switched. Matt > --Kai > > > > On Tue, May 4, 2010 at 12:51 PM, Jed Brown <jed at 59a2.org> wrote: > >> On Tue, 4 May 2010 11:37:14 -0500, Matthew Knepley <knepley at gmail.com> >> wrote: >> > I see. Yes, it currently uses the makefile organization. This is the >> > kind of metadata that Barry would like in a DB rather than in >> > makefiles. >> >> It would be easy to convert between being spread out in the makefiles >> and being held in some central location. For instance, something like >> builder.py, run at the end of configuration time, could instead of >> building the project, write a single tupfile [1] for all of PETSc, and >> then we could rejoice with fast correct builds, even after >> reconfiguring. >> >> I think the metadata itself belongs with the implementations (more or >> less where it is currently) unless we are actually working with an >> image-based system (which does not look likely in the near future). >> >> Jed >> >> [1] For those who not in the know: http://gittup.org/tup/make_vs_tup.html >> > > > > -- > Kai Germaschewski > Assistant Professor, Dept of Physics / Space Science Center > University of New Hampshire, Durham, NH 03824 > office: Morse Hall 245E > phone: +1-603-862-2912 > fax: +1-603-862-2771 > > -- 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/0373cd88/attachment.html>
