[petsc-dev] buildsystem: cusp location

[Barry Smith]

  Side note. We should remove the --download-thrust and --download-cusp options. 

   Barry

On Mar 25, 2012, at 12:16 PM, Satish Balay wrote:

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