[petsc-dev] ugliness due to missing lapack routines

[Karl Rupp]

Hi Jed,

> If we we did negative defines
>
> #define PETSC_HAVE_SOMETHING 0
>
> then we could have normal code
>
>    if (PETSC_HAVE_SOMETHING) {
>      some_func(ibuprofen);
>   } else { ... }
>
> The problem with this is that (a) we always need to define everything so
> petscconf.h becomes larger and configure becomes more tightly coupled in
> some ways, and (b) any use of #if defined(PETSC_HAVE_SOMETHING) will
> evaluate true even for a negative define. This last instance is such a
> confusing source of bugs that almost every project avoids it.

(a) might lead to a larger petscconf.h, but at the same time it always 
contains a full list of packages that can be used within PETSc. I 
wouldn't consider this to be a drawback.

Fortunately, b) can be checked easily with 'style checkers', keeping the 
lifetime of such a bug below 1 day.


> To convert this to usual C semantics, we could use (yet another) macro trick

Replacing CPP with CPP to get rid of CPP? That does not sound like a 
good approach :-D


> With this sort of thing, we could write
>
> if (PETSC_HAVE_(SOMETHING)) {
>    some_func(no_headache);
> } else { ... }
>
> which can be reasoned about using normal C semantics. The condition
> evaluates at compile time so the code produced (with any optimization)
> is identical. If different functions are called in the two cases, the
> linker may request both of them. (This can be good or bad.)

Since #if defined(...) is often used to conditionally enable calls to 
external libraries, this would require us to either disallow all direct 
calls to external libraries in all of PETSc core (and use some 
sublibrary-type generic interface instead), or to always link against 
all libraries. The latter is a nightmare with respect to 
support-requests to petsc-maint.

Best regards,
Karli