new build system

[Leif Strand]

Stephan Kramer wrote:
> In that respect a related question: is it really necessary to have
> incompatible changes between sub-sub-versions of PETSc? Most software
> only makes backwards-incompatible changes when bumping their mayor
> version number. I must say that I was not really amused when I found out
> our software would not build with PETSc 2.3.3, because of various small
> namechanges, such as KSPSetMonitor -> KSPMonitorSet.


I second all of this. This is a much bigger issue than build system, 
directory layout, etc. As a library maintainer, one needs religion about 
this sort of thing. I would expect any library not to make gratuitous 
changes to the API from one update to the next, and to have a sane 
version numbering scheme.

So the number of changes between PETSc 2.3.2 and 2.3.3 was a bit 
surprising. Given that it adds new features (Sieve), one could argue 
that it should have been called PETSc 2.4. Given the number of 
incompatibility-inducing changes (order-of-args for 
VecScatter{Begin,End}, KSPDefaultSMonitor -> KSPMonitorDefault, etc.) I 
would argue it should have been called PETSc 3.0. If you're really 
ambitious, you could implement a separate API layer, and applications 
can choose which API version they want to use (using a #define, for 
example). Otherwise, branch management is a must.

Regarding multiple configurations: I would try to reduce the number of 
possible configurations, rather than invent an elaborate 
multi-configuration install/build directory layout scheme. Ideally, 
there should be only one possible configuration. Decide upon one way of 
doing things.

A common mistake is to punt on every single difficult design decision by 
turning it into an "option". Over time, this leads to huge "Preferences" 
dialogs and configure scripts with a hundred options. This places a 
burden upon the end user; they won't thank you for being offered so many 
choices. Regarding PETSc, one of my pet peeves is the "--with-c-support" 
option. Why not just *always* wrap everything in [extern "C"]? Not only 
is the default wrong; this is a non-option. I can't think of any reason 
why anyone would even want a choice. Taking a step back, 
"--with-clanguage" is evil as well. At some point, you should decide 
whether PETSc is C code, or C++ code.

Another common mistake is to make decisions at configure/compile-time 
that could be made at runtime. I've seen people insert #ifdef X when "if 
(x) {}" would have worked just as well. Regarding PETSc, applying this 
principle to dependencies might be helpful. For example, pretend I want 
to switch from Chaco to Parmetis or vice-versa. AFAIKT, the current 
situation is that I would need two completely different 
builds/configurations of PETSc. Ideally I could do it at runtime using 
some sort of partitioner-plugin scheme. This might mean splintering 
parts PETSc off into separate satellite packages (e.g., "the Chaco 
plug-in for PETSc"). Debian/RPM packagers would thank you for it.

--Leif Strand