[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

On Thu, Feb 7, 2013 at 1:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> > Since this is only BLAS-related, we should move all the BLAS-calls to a
> separate package with the sole purpose of providing a unified (binary)
> interface for the PETSc core. This will allow us to keep the PETSc core
> clean and put all the ugly stuff in that 'unification sublibrary'. This
> should eliminate any BLAS-related CPP usage from the PETSc core.
>

I agree with this. This beastie may as well expose a C interface and have
proper error handling while we're at it. If it had a SetErrorHandler(), we
could wire it up to call back into PetscError, in which case we'd be able
to call it like a normal C function.

>
> >>    Sometime I will send a detailed email explaining why I wish to
> totally eradicate CPP.
> >
> > This is a noble goal with my full support, yet very hard to achieve. How
> do we want to tackle CHKERRQ for example?
>
>    This is actually an easy one. Once we have a pure C code that can be
> completely represented in a full AST, then it is trivial to have a "pretty
> printer" that automatically adds into the code the equivalent of __FUNC__,
> PetscFunctionBegin/End, CHKERRQ(), PetscStackCall() etc BEFORE passing the
> code into the compiler to be compiled down to object code.
>
>    Thus PETSc will actually ultimately become simpler C code without all
> the additional stuff we have added for error checking/handling etc.  Happy
> days :-)


I think this would be bad. It creates lots of build system complexity and
will make error messages trace through the generated code that we never see
explicitly. I don't think you can do this sort of source modification
without the abstraction being leaky and seemingly magical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/45666483/attachment.html>