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

Jed Brown jed at 59A2.org
Tue May 4 13:30:52 CDT 2010


On Tue, 4 May 2010 14:08:42 -0400, 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.

The kernel probably has better controlled dependencies than the Tup
author's synthetic benchmarks.  Your numbers are still not far from his.

> That's a project which is way larger than petsc, and make does a "good
> enough" job there.

Yes, a do-nothing non-recursive build of PETSc using make takes well
under a second which is "good enough" for me.  Tup is ultra-scalable,
but PETSc is not nearly big enough to require that.

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

CMake, for example, does a sort of recursive make, but it's generally
fast (almost as fast as non-recursive) and correct.  They do nontrivial
work at configure and generate time to obtain that.  I think that sort
of build-system-generator concept is actually good, especially if IDE
interoperability is a requirement.

> 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 agree with this.

Jed



More information about the petsc-dev mailing list