[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

On Feb 7, 2013, at 5:50 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Thu, Feb 7, 2013 at 5:42 PM, Matthew Knepley <knepley at gmail.com> wrote:
> Hmm, it seems like the easiest thing to do is delete them if they don't exist.
> 
> How will you deal with headers that were determined unsafe or undesirable to import (e.g., complex.h conflicts with hypre)? Or feature test macros?

   We need to (1) categorize the uses of CPP today and (2) determine which can be fixed within the usual C language syntax and which will require the new tools (the new source manipulation tools)

> 
> Where does the code guarded by PETSC_HAVE_4ARG_SIGNAL_HANDLER go? What about PETSC_HAVE_SIGINFO_T? These aren't single-line pieces of code, but you're going to move all that stuff into generated files? How are you going to tell the generator what to generate in all these cases? What does that achieve?

   These all have to be categorized and dealt with. For ugly #ifdef stuff for dealing with slightly different system call interfaces I think the best approach would be to define a common interface, use that one common interface from PETSc source and then put the "patch" code that mates the true system stuff to the common interface in a separate place (whether that code is generated or stuck in some files somewhere is not important; in the same way that it doesn't matter where the LAPACK coupling code is done). The key is that PETSc code is pure C and thus can be easily manipulated, unlike the current situation.

   Barry