<p>I'm for strict, precise semantics over fuzzy permissive  semantics. I don't think being permissive is likely to cause harm, so I'm fine with checking both.</p>
<p>I just don't want the extra /include to be a required part because it breaks consistency with other packages (none of which require the extra /include).</p>
<div class="gmail_quote">On Mar 25, 2012 9:20 PM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
   So you are arguing we should make life harder for users?<br>
<br>
   --with-package-dir=dir   currently has the model "look for any way we know about" for installs underneath dir.<br>
<br>
   Why is this a bad model? Why do you advocate something much more limited?<br>
<br>
   Who agrees with Sean that we should cripple --with-package-dir=dir?   Expanding it sounds like a better idea.<br>
<br>
   Barry<br>
<br>
<br>
<br>
On Mar 25, 2012, at 4:56 PM, Sean Farley wrote:<br>
<br>
><br>
><br>
> Yes, I think it would be far simpler to say:<br>
><br>
> --with-package-dir = prefix install<br>
> --with-package-{include,lib}dir = non-prefix type of package<br>
><br>
> 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.<br>

><br>
> Sure better errors are useful. This is independent of the<br>
> package-dir=prefix issue.  [so you can add this stuff now.]<br>
><br>
> That's true.<br>
><br>
> apt-get install should already work. And --with-package-dir is<br>
> generally for manual installs.<br>
><br>
> 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.<br>
<br>
</blockquote></div>