[petsc-dev] What is this for?

[Barry Smith]

On Nov 15, 2011, at 10:44 PM, Jed Brown wrote:

> On Tue, Nov 15, 2011 at 22:39, Barry Smith <bsmith at mcs.anl.gov> wrote:
>   Ideally we would not need to list the information separate from the source file. What should happen is the BuildSystem parses each source file, determines what includes are used and then passes to the compiler exactly the correct -I and no extra.  Or as alternative the BuildSystem behaves like CPP and actually puts the exact full path for each include into the source code just before passing it to the compiler. This takes the whole bothersome problem of the compiler searching through the -I paths to find the first include file with the same name and including it. In other words BuildSystem takes on more parts of the compile process away from the untrustworthy UNIX tools for compiling and linking.
> 
> I agree with the rest of your mail, but not this part. I think that the build environment should be managed in essentially the same way for library source code and examples. I also think it's important that examples be relocatable to a user's own project and built with simple tools. If the build system is doing goofy preprocessing, then users won't be able to build it easily with their own tools.

   This concern is appropriate. But the examples will not need "googy preprocessing" they will be regular old C/C++/Fortran code. Note that in general the examples do not need includes for particular external packages or #if PETSC_HAVE_... stuff. If the user wants one of the external package include then they can use PETSC_PARMETIS_INCLUDE or whatever in their makefiles for those includes to be found. So in short, no goofy preprocessing for examples!

  Barry

Yes, we'll need to make sure that the public PETSc include files don't require goofy preprocessing but I think that is possible, it is only the source code files (and maybe some private include files) that need the goofy preprocessing.