<div class="gmail_quote">On Sun, Mar 25, 2012 at 11:59, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":67r">When configure is doing --download-cusp - it can determine how cusp is<br>
organized. [I think we try to place in PETSC_DIR/PETSC_ARCH/include.<br>
But since cusp decides how it installs itself [say user installs and<br>
installs manually] - we try to support that mode using<br>
--with-cusp-dir= option. There is no 'include/' dir in that mode of<br>
install.<br></div></blockquote><div><br></div><div>Well isn't that what --with-cusp-include= is for?</div><div><br></div><div>I even wouldn't object to being lenient, but I don't think it makes sense to abuse the meaning of --with-cusp-dir=.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":67r">
<br>
Yes - currently the situation is not ideal. The ideal situation is<br>
folks install cusp thrust - the recommended way - i.e along with cuda<br>
in cuda includes. One has to do this with thrust anyway - otherwise<br>
nvcc will always pick up thrust bundled with cuda - and now what you<br>
specify with -I/path-to-thrust.<br>
<br>
The other problem currently with cusp/thrust is - we've been using dev<br>
snapshot of cusp/thrust for a while. I don't know if there is a<br>
release snapshot of these packages that we can switch to now [or not].</div></blockquote></div><br>