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. > >
