<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They give 2 options . [one /usr/local/cuda/include, the other<br>
/home/nathan/cuda_libraries/cusp]<br></blockquote><div><br></div><div>I'd like to point out that many (if not the majority of) times we (i.e. BuildSystem logic) isn't working with what the user installed by hand but rather by one of the many package managers: apt-get, ports, rpm, arch, etc. These package managers all dictate a prefix install with few exceptions; regardless of what the package writer really prefers. Again, we even do the same with --download-package (placing headers in $PETSC_ARCH/include)</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For your consistancy [wrt to santity of prefix definition] you say -<br>
petsc configure should support 1 wirh packaage-dir - and users who<br>
choose 2 should use --with-package-includ option. I don't agree with<br>
this logic.<br></blockquote><div><br></div><div>I understand you don't agree. The --with-package-dir=prefix would be able to clean up and unify a lot of code in BuildSystem and I haven't seen a good counter-point besides the fact that you don't like it.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We don't really insist on --with-package-dir=prefix. So far we've been<br>
accomodating varations of 'package installs' that we could reasonably<br>
support.<br></blockquote><div><br></div><div>And the code in each package.py reflects this schism.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im">But based on the your previous statement - we should not support mkl</div>
organiztion with --package-dir option [as it doesn't comply with<br>
prefix organizaton], insist users should always --with-package-lib<br>
option.</blockquote><div><br></div><div>We're using python. We can overload and use inheritance (or whatever fancy design pattern you want; i.e. decorator) and change the default behavior if a package really misbehaves like MKL.</div>

<div><br></div><div>To recap, what I'm suggesting is the following:</div><div><br></div><div>1) Change the meaning of --with-package-dir to be a prefixed install</div><div><br></div><div>2) Report a meaningful error if a wanted file is not found. In the cusp example:</div>

<div><br></div><div><div>===============================================================================</div><div>             Configuring PETSc to compile on your system                       </div><div>===============================================================================</div>

<div>TESTING: checkInclude from config.headers(config/BuildSystem/config/headers.py:86)                                                                                                                                                            *******************************************************************************</div>

<div>         UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log for details):</div><div>-------------------------------------------------------------------------------</div><div>--with-cusp-dir=/Users/sean/local/include does not seem to contain cusp/version.h; did you want to specify this with --with-cusp-includedir?</div>

<div>*******************************************************************************</div></div><div><br></div><div>3) Override this behavior for certain packages like MKL</div><div><br></div><div>I like this more than the current behavior of --with-package-dir because the location is well-defined and not "how did this particular developer layout his package? i have no idea since I installed using apt-get!!"</div>

</div>