[petsc-dev] ugliness due to missing lapack routines
Barry Smith
bsmith at mcs.anl.gov
Thu Feb 7 22:05:55 CST 2013
On Feb 7, 2013, at 9:58 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>
> On Thu, Feb 7, 2013 at 7:20 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 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.
>
> We'll always have system stuff and stuff related to other libraries in headers.
True. Minimizing it as much as possible will make the rest of the job easier.
>
> I think it really matters how those bits of code are managed because that's something we have to teach the code manipulator about.
The reason I am insistent on minimizing CPP is that it is easy to teach a pure C manipulator stuff. It is very difficult (I submit) to teach a CPP + C manipulator much of anything expecially when "nasty" CPP tricks are used. Plus there are good C manipulation tools coming on line, there are no, and never will be, good CPP + C manipulation tools.
Barry
> That is, if the code you want to manipulate does not use CPP, or you can teach the manipulator about those bits of CPP (like CHKERRQ), then it's not a problem to code manipulation. And if you have some "other" system for PetscOptions (which is an important macro that is used all over the place), the manipulator still needs to know enough about the semantics of that construct to not mess it up.
More information about the petsc-dev
mailing list