On Sun, 25 Mar 2012, Sean Farley wrote:

...

They give 2 options . [one /usr/local/cuda/include, the other /home/nathan/cuda_libraries/cusp]

I'd like to point out that many (if not the majority of) times we (i.e. BuildSystem logic) isn't working with what the user installed by hand but rather by one of the many package managers: apt-get, ports, rpm, arch, etc. These package managers all dictate a prefix install with few exceptions; regardless of what the package writer really prefers. Again, we even do the same with --download-package (placing headers in $PETSC_ARCH/include)

For one if package managers install stuff [that are distribution compliant] - users don't need to specify --with-package-dir option at-all. Compilers automatically find includes/libs [ and package.py defaults to checking this mode first.] package-dir option is used primarily for non-[apt,yum] installed stuff - either by user or sysadmin. Note: there is no such package for cusp/thrust to base a default - so the upstream default thats currently implemented is fine [we are supporting actuall use cases instead of fictious ones that don't exist]. If such a package actually existed - then compilers would find cusp/thrust automatically.

For your consistancy [wrt to santity of prefix definition] you say -

...

petsc configure should support 1 wirh packaage-dir - and users who choose 2 should use --with-package-includ option. I don't agree with this logic.

I understand you don't agree. The --with-package-dir=prefix would be able to clean up and unify a lot of code in BuildSystem and I haven't seen a good counter-point besides the fact that you don't like it.

I agree about the cleanup part. But thats beside the point. I thought the motivation so far was user convinence [and autodetect as many user configs as possible] - hence the extra code in buildsystem.

We don't really insist on --with-package-dir=prefix. So far we've been

...

accomodating varations of 'package installs' that we could reasonably support.

And the code in each package.py reflects this schism.

But based on the your previous statement - we should not support mkl

...

organiztion with --package-dir option [as it doesn't comply with prefix organizaton], insist users should always --with-package-lib option.

We're using python. We can overload and use inheritance (or whatever fancy design pattern you want; i.e. decorator) and change the default behavior if a package really misbehaves like MKL.

To recap, what I'm suggesting is the following:

1) Change the meaning of --with-package-dir to be a prefixed install

I think we support this for packages that actually have a concept of prefix-install. But what you are actually saying is: if a user installs an externalpackage separately [that doesn't comply with a prefix install] - then s/he should reinstall [with some manual hacks] per some prefix guidelines specified by petsc - so that s/he might provide --with-package-dir option to petsc configure. I don't claim the current mode works for all curent user installs - but so far - when it failed - we would recommend --download-package as a better alternative. [it also deals with other types of incompatibilities aswell]. One of the sugestions in this thread was for the user to specify --with-include/with-lib options instead of --with-dir - for such cases.

2) Report a meaningful error if a wanted file is not found. In the cusp example:

=============================================================================== Configuring PETSc to compile on your system

=============================================================================== TESTING: checkInclude from config.headers(config/BuildSystem/config/headers.py:86)

******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- --with-cusp-dir=/Users/sean/local/include does not seem to contain cusp/version.h; did you want to specify this with --with-cusp-includedir? *******************************************************************************

Sure better errors are useful. This is independent of the package-dir=prefix issue. [so you can add this stuff now.]

3) Override this behavior for certain packages like MKL

I like this more than the current behavior of --with-package-dir because the location is well-defined and not "how did this particular developer layout his package? i have no idea since I installed using apt-get!!"

apt-get install should already work. And --with-package-dir is generally for manual installs. Satish