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
