[petsc-dev] buildsystem: cusp location

[Jed Brown]

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.

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).
On Mar 25, 2012 9:20 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:

>
>   So you are arguing we should make life harder for users?
>
>   --with-package-dir=dir   currently has the model "look for any way we
> know about" for installs underneath dir.
>
>   Why is this a bad model? Why do you advocate something much more limited?
>
>   Who agrees with Sean that we should cripple --with-package-dir=dir?
> Expanding it sounds like a better idea.
>
>   Barry
>
>
>
> On Mar 25, 2012, at 4:56 PM, Sean Farley wrote:
>
> >
> >
> > Yes, I think it would be far simpler to say:
> >
> > --with-package-dir = prefix install
> > --with-package-{include,lib}dir = non-prefix type of package
> >
> > 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.
> >
> > Sure better errors are useful. This is independent of the
> > package-dir=prefix issue.  [so you can add this stuff now.]
> >
> > That's true.
> >
> > apt-get install should already work. And --with-package-dir is
> > generally for manual installs.
> >
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120325/72b27b82/attachment.html>