<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For one if package managers install stuff [that are distribution<br>
compliant] - users don't need to specify --with-package-dir option<br>
at-all. Compilers automatically find includes/libs [ and package.py<br>
defaults to checking this mode first.] </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
package-dir option is used primarily for non-[apt,yum] installed stuff<br>
- either by user or sysadmin.<br></blockquote><div><br></div><div>... or if a package is installed into a path that isn't search by default with the compiler? ./configure --with-cusp --with-cuda --with-thrust gives</div>
<div><br></div><div><div> UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details):</div><div>-------------------------------------------------------------------------------</div><div>You must specify a path for cusp with --with-cusp-dir=<directory></div>
</div><div><br></div><div>even though mpicc -show gives</div><div><br></div><div>/opt/local/bin/gcc-mp-4.6 -I/opt/local/include ...</div><div><br></div><div>and /opt/local/include/cusp/version.h exists.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note: there is no such package for cusp/thrust to base a default - so<br>
the upstream default thats currently implemented is fine [we are<br>
supporting actuall use cases instead of fictious ones that don't<br>
exist].</blockquote><div><br></div><div>Huh? As Jed pointed out, archlinux has it. MacPorts also has it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If such a package actually existed - then compilers would find<br>
cusp/thrust automatically.<br></blockquote><div><br></div><div>How?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">I agree about the cleanup part. But thats beside the point. I thought</div>
the motivation so far was user convinence [and autodetect as many user<br>
configs as possible] - hence the extra code in buildsystem.<br></blockquote><div><br></div><div>No, I'm really just trying to iron out a policy, more or less, about --with-package-dir. Implementation would need to follow that; but as I said before, I'm no good at Jenga. Specifically, I've tried to add search paths, such as /opt/local, but this always ends up breaking other use cases.</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">I think we support this for packages that actually have a concept of prefix-install.</div></blockquote><div><br></div><div>It's supported for any package that sets self.includedir='include'.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But what you are actually saying is: if a user installs an<br>
externalpackage separately [that doesn't comply with a prefix install]<br>
- then s/he should reinstall [with some manual hacks] per some prefix<br>
guidelines specified by petsc - so that s/he might provide<br>
--with-package-dir option to petsc configure.<br></blockquote><div><br></div><div>Not at all; no reinstall should be necessary. I'm suggesting that the user just specify --with-package-{include,lib}dir. Why do we have these options if not for this purpose?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't claim the current mode works for all curent user installs -<br>
but so far - when it failed - we would recommend --download-package as<br>
a better alternative. [it also deals with other types of<br>
incompatibilities aswell]. One of the sugestions in this thread was<br>
for the user to specify --with-include/with-lib options instead of<br>
--with-dir - for such cases.<br></blockquote><div><br></div><div>Yes, I think it would be far simpler to say:</div><div><br></div><div>--with-package-dir = prefix install</div><div>--with-package-{include,lib}dir = non-prefix type of package</div>
<div><br></div><div>And then we'd have less ambiguity. Packages such as MKL are already exceptions to whatever is defined currently, so there'd be no more code to add to handle this, i.e. MKL would remain an exception in the new model.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure better errors are useful. This is independent of the<br>
package-dir=prefix issue. [so you can add this stuff now.]<br></blockquote><div><br></div><div>That's true.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
apt-get install should already work. And --with-package-dir is<br>
generally for manual installs.</blockquote><div><br></div><div>apt-get only works because /usr/local is listed as a default search path. Perhaps gcc should have been configured to add its own prefix but that would have to be an issue taken up with each package manager.</div>
</div>