[petsc-dev] petsc release soon

[Barry Smith]

  I still like including the private in the name since it makes clear they are private include files.

   Barry

On Mar 12, 2012, at 2:30 PM, Jed Brown wrote:

> On Mon, Mar 12, 2012 at 14:09, Satish Balay <balay at mcs.anl.gov> wrote:
> 1. the convention to avoid such conflict is not renaming internal dirs
> - but using a toplevel namespaced dir.
> 
> i.e /usr/include/petsc/petsc.h, /usr/include/petsc/private etc..
> 
> 2. I think autoconf supports options to choose the include install in
> either /usr/include or /usr/include/petsc. [is it the includedir
> option?]
> 
> Well it's totally unacceptable to make users -I$prefix/include/petsc, so if we change to this convention, it has to be the same in the source directory.
> 
> $PETSC_DIR/include/petsc/vec.h
> 
> and users do #include <petsc/vec.h>. This model is used by boost, valgrind, and the linux kernel, but that breaks existing code for no good reason.
> 
> The other model of a handful of prefix/include/packagexxx.h and private headers in prefix/include/package/*.h is used by KDE, krb5, libssh, and lzma.
> 
> Both of these are very common and you'll find tons of examples in your /usr/include. /usr/include/package-private/ is only used by Tk. I much care, but using prefix/include/petsc/ for private stuff is the closest convention to the current model.
> 
>