[petsc-dev] (no subject)

[Jed Brown]

On Sat, Feb 16, 2013 at 5:53 AM, Matthew Knepley <knepley at gmail.com> wrote:

> > Splitting petscconf.h by package or something would be cool because when
>> reconfigure runs, any changes to petscconf.h usually don't affect anything,
>> but I think trying to do that would be a maintenance disaster.
>>
>>    Might not be too bad actually. If the Package class itself just
>> handled it as a matter of course, declaring Info with a package (and when
>> called from within a package) would automatically to into its own list and
>> then its own file.
>
>
> The file that it outputs into is set by the object, so all you need to do
> is reset the header filename in the
> constructor for Package.
>

The reason I thought it was hazardous was if, say, someone classified
PETSC_HAVE_HYPRE as being relevant to KSP/PC, then anyone testing for it
from code in petscmat would come up false for no apparent reason. To figure
out why it's false, we would have to look through the petscconfxxx.h files,
which is just more confusing.

An alternative is to #define PETSC_HAVE_X 0 instead of leaving it
undefined, so that we can get a compilation error when we haven't included
the right conf header. This would convert a lot of #if defined(X) ...
#endif code to non-cpp if (X) { ... }.

Note that we could #define PETSC_HAVE_X_UNDEFINED 1 and write a
PETSC_HAVE_(X) macro that errors if neither PETSC_HAVE_X or
PETSC_HAVE_X_UNDEFINED is available, thus tests based on defined state
would still be valid, but we could alert the user when they need to
reconfigure.

I just don't know if any of this is worth it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130216/6e9e60d2/attachment.html>