new build system

[Barry Smith]

On Thu, 14 Jun 2007, Leif Strand wrote:

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

  Leif,

    Thanks for your comments; lots to absorb.

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

  There may be some confusion here but this is not true. You should build PETSc with
both Chaco and Parmetis and then choose at run time which one you want. You certainly
should not maintain two PETSc's for this.

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

  Here I am afraid we feel into the "configure; make" trap where ALL the configuring
is done and then ALL the make. It would be possible (pretty easy mostly) to configure
PETSc with Blas/Lapack/MPI, make it and then seperately at any later time configure
and add the "plugins". I'm not sure how we would manage that though.

 A general comment to all the installers: we appreciate your comments and take them
seriously, in the end we may make decisions you may not like but that is not because
we think you are wrong or ignored you it is just because either (1) other constraints
prevented us from doing things better or (2) we were not clever enough to figure 
how to satisfy everyone's desires.

   Barry

  
> 
> --Leif Strand
> 
>