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

[Kai Germaschewski]

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.

--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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100504/eb2bd46c/attachment.html>