[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

On Feb 7, 2013, at 11:55 AM, Karl Rupp <rupp at mcs.anl.gov> wrote:

> Hi Barry,
> 
>>>   In fact Matt can also generate the appropriate zdot_() when needed so ugly crap like
>>> /* handle complex dot() with special code */
>>> 
>>> How are you going to avoid a namespace collision here? The problem isn't that the function doesn't exist, it's that we can't determine its binary interface.
>> 
>>    Crap you are right. We'll need to come up with some other solution UNLESS the BLAS library version of them are in their separate .o files so we can pick up the generated one in libpetsc.a and it won't ever load the one in the blas library.
> 
> 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.
> 
>>    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 :-)

   Barry


> I don't know of any other way of extracting file names and line numbers without blowing up the code base. If you are aiming towards compiler-driven code development/generation by having the full AST available, we could still play a few compatibility-tricks to make this work for a handful of macros.
> 
> Best regards,
> Karli