[petsc-dev] buildsystem: cusp location

[Satish Balay]

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