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

[Jed Brown]

On Wed, 5 May 2010 00:36:55 -0700 (PDT), Farshid Mossaiby <mossaiby at yahoo.com> wrote:
> I have been recently reading about SCons, www.scons.org. May I know
> how does it compare to your other options? They claim that their build
> system is completely portable and coded in pure python.

My biggest complaint about SCons is that it conflates configuration with
the build itself.  This limits what sort of setup can be done and
contributes to SCons being the slowest build system in existance.  To
fight this extreme slowness, people usually do more and more caching
(many projects also fork SCons in the process) and the cache invariably
becomes stale so you end up with a broken build, and the way to fix it
is to wipe the cache and start from a clean slate (back to being very
slow).

It has a thing called "variants" (the analogue of multiple PETSC_ARCHes)
but it's nontrivial to keep variants working properly in a complex
project (I've rarely found projects that keep them working).

SCons is pretty inadequate at cross-compiling (important if in
batch-submission environment where the interactive nodes are different
from compute nodes).  The code quality in SCons itself is pretty bad.
My cynical view is that main advantage of SCons is that it does
dependency analysis without having to write rules for them (or rules to
generate them with $(CC) -MD, etc).  A secondary advantage is that
simple configuration tests can be done in SCons without needing a real
configuration system, but the performance issue/caching complications
show up as soon as these tests take more time than you want to spend on
every incremeental rebuild.

There are lots of newer Python build systems that I think are better
than SCons.  Note that despite the proliferation of build tools claiming
to be portable and extensible, Google chose to create yet another for
Chromium (GYP="Generate Your Projects").

My favorite build system is probably Cabal, but it is essentially
Haskell-only (it can have external dependencies such as C libraries, but
the correctness and portability guarantees go away because they can't be
enforced by the language's module system).

I think that PETSc's BuildSystem is pretty good as a configuration
system, and the logic to portably build third-party dependencies like
MUMPS is certainly unique [1].  But PETSc's makefile system is horrible
because it does no dependency analysis and is extremely slow.

Jed

[1] Dave May has sold PETSc to MUMPS users purely on the basis of it
being an easier way to install MUMPS.