On Sun, 25 Mar 2012, Sean Farley wrote:

On Sun, Mar 25, 2012 at 12:27 PM, Jed Brown <[email protected]> wrote:

...

On Sun, Mar 25, 2012 at 12:16, Satish Balay <[email protected]> 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