<div class="gmail_quote">On Mon, Mar 12, 2012 at 14:09, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":7dc">1. the convention to avoid such conflict is not renaming internal dirs<br>
- but using a toplevel namespaced dir.<br>
<br>
i.e /usr/include/petsc/petsc.h, /usr/include/petsc/private etc..<br>
<br>
2. I think autoconf supports options to choose the include install in<br>
either /usr/include or /usr/include/petsc. [is it the includedir<br>
option?]</div></blockquote></div><div><br></div><div>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.</div><div>
<br></div><div>$PETSC_DIR/include/petsc/vec.h</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div>