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
