On Mar 12, 2012, at 1:57 PM, Matthew Knepley wrote: > On Mon, Mar 12, 2012 at 1:41 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Mar 12, 2012, at 1:36 PM, Jed Brown wrote: > > > On Mon, Mar 12, 2012 at 13:30, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > A couple maintenance issues that I think should be addressed. > > > > 1. Namespace EVERYTHING in conf/variables and > > $PETSC_ARCH/conf/petscvariables. It should be safe to include these files > > in someone else's makefile without conflicting with their own stuff. > > > > 2. Rename all C++ files to *.cxx or whatever so that it's possible to build > > C++ plugins/implementations, with everything else built using a C compiler. > > > > 3. Move all private headers from include/private/ to include/petsc/ > > (convention adopted by hundreds of packages) or include/petsc-private/ > > (like Tk). > > I prefer petsc-private because if one installs in the xxxx/petsc/ you get > this stupid looking xxxx/petsc/include/petsc. Better > xxxx/petsc/include/petsc-private > > I agree that petsc/include/petsc is stupid. I see no reason to change the > perfectly logical include/private just to match what > some idiot programmers did.
I agree with Jed here. The problem now is if you install PETSc you get something like /usr/include/private/vecimpl.h etc etc. Someone just looking at that directory doesn't know it is associated with petsc while /usr/include/petsc-private/vecimpl.h makes that clear. Barry > > Matt > > > Barry > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
