[petsc-dev] buildsystem: cusp location

[Satish Balay]

On Sun, 25 Mar 2012, Jed Brown wrote:

> On Sun, Mar 25, 2012 at 11:59, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > When configure is doing --download-cusp - it can determine how cusp is
> > organized. [I think we try to place in PETSC_DIR/PETSC_ARCH/include.
> > But since cusp decides how it installs itself [say user installs and
> > installs manually] - we try to support that mode using
> > --with-cusp-dir= option. There is no 'include/' dir in that mode of
> > install.
> >
> 
> Well isn't that what --with-cusp-include= is for?
> 
> I even wouldn't object to being lenient, 

you mean detect all possible locations related to user specified
--cups-dir option? This is a fine aproach - I guess we should fix
cusp/thrust to do this.  [i.e sean's option(1) ].

> but I don't think it makes sense to abuse the meaning of
> --with-cusp-dir=.

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

> > Yes - currently the situation is not ideal. The ideal situation is
> > folks install cusp thrust - the recommended way - i.e along with cuda
> > in cuda includes. One has to do this with thrust anyway - otherwise
> > nvcc will always pick up thrust bundled with cuda - and now what you
> > specify with -I/path-to-thrust.

Even if we sort out the previous issue - this conflict with default thrust
will continue to exist [I'll say this as nvcc bug.]

Satish

> > The other problem currently with cusp/thrust is - we've been using dev
> > snapshot of cusp/thrust for a while. I don't know if there is a
> > release snapshot of these packages that we can switch to now [or not].
> >
>