On Feb 7, 2013, at 6:39 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 5:58 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > 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. > > I think BLAS is substantial enough to follow Karl's suggestion and factor it > *out* of PETSc. I don't think we really get anywhere by doing that for system > stuff. The whole point of many of the interfaces in src/sys/ is to hide that > stuff from the rest of PETSc. Of course we have to write that code somewhere > and it's not at all clear to me that "generating that code" offers any value. You are too hung up on the "generating" that code. The issue is to have a "complete" software base that is machine manipulatable, how the tiny bit of code that is not manipulatable is manage is not central to the discussion. But note that have non-machine manipulatable in the include directory files pretty much means that no code will be machine manipulatable. Barry
