[petsc-dev] buildsystem: cusp location

Barry Smith bsmith at mcs.anl.gov
Mon Mar 26 12:12:30 CDT 2012


On Mar 25, 2012, at 10:31 PM, Jed Brown wrote:

> 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).

  Given our --with-package-dir model of checking all kinds of possibilities I don't see why that extra include would be required part? Isn't it just one possibility?

  What is the argument about, just have cusp.py check more possibilities.

   Barry

> 
> 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.
> 




More information about the petsc-dev mailing list