[petsc-dev] buildsystem: cusp location

Satish Balay balay at mcs.anl.gov
Sun Mar 25 13:47:49 CDT 2012


On Sun, 25 Mar 2012, Sean Farley wrote:

> On Sun, Mar 25, 2012 at 12:27 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
> > On Sun, Mar 25, 2012 at 12:16, Satish Balay <balay at mcs.anl.gov> wrote:
> >
> >> I don't see how the above is abusing --with-cusp-dir=
> >> option. --with-package-dir option - by definition is to specify the
> >> default install root dir of the given package. [assuming all packages
> >> default to PACKAGE_DIR/include is wrong].
> >>
> >
> > Okay, but apparently we see it installed this way in practice.
> >
> 
> To follow-up on this, this is even the practice we have when installing
> packages specified with --download. So, why can't we specify
> --with-package-dir to have a common structure
> (PACKAGE_DIR/{include,lib,lib64,lib32,bin,share,etc}) and if the user
> doesn't have that structure, then have them use the
> --with-package-{include,lib} options? I'm at a loss for which cases that
> doesn't cover.

The default organization for --with-package-dir should be the default
organization used by the package - not what petsc configure dictates
whats suitable for itself. For ex: look at MKL - and the wierd path
scheems it has developed over the past many versions. We support most
of them.

However there is a bit of autodetection in --with-package-dir - and if
one wants to skip this [because they know better] - then
--with-include,-with-lib is the correct thing to do. We do this when
petsc configure builds externalpackages [petsc configure tells the
configure of external package exactly what do do - instead of letting
it autodetect - stuff petsc configure already detected] etc..


Note1: To some extent --download-package is internal to petsc - so if
it changes the default organiztion for packages - its fine by me [aka
cusp/thrust]

Note2: We might not support 'default organization' for all
externalpackages. [for packages that are primarily installed with
--download-package option - where we modify internal buildtools - for
ex: native lapack from netlib, blacs etc?].

Satish



More information about the petsc-dev mailing list