[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new build system

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