[petsc-dev] buildsystem: cusp location

[Sean Farley]

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

... or if a package is installed into a path that isn't search by default
with the compiler? ./configure --with-cusp --with-cuda --with-thrust gives

         UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log for
details):
-------------------------------------------------------------------------------
You must specify a path for cusp with --with-cusp-dir=<directory>

even though mpicc -show gives

/opt/local/bin/gcc-mp-4.6 -I/opt/local/include ...

and /opt/local/include/cusp/version.h exists.

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


Huh? As Jed pointed out, archlinux has it. MacPorts also has it.


> If such a package actually existed - then compilers would find
> cusp/thrust automatically.
>

How?


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

No, I'm really just trying to iron out a policy, more or less, about
--with-package-dir. Implementation would need to follow that; but as I said
before, I'm no good at Jenga. Specifically, I've tried to add search paths,
such as /opt/local, but this always ends up breaking other use cases.

I think we support this for packages that actually have a concept of
> prefix-install.
>

It's supported for any package that sets self.includedir='include'.


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

Not at all; no reinstall should be necessary. I'm suggesting that the user
just specify --with-package-{include,lib}dir. Why do we have these options
if not for this purpose?

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

Yes, I think it would be far simpler to say:

--with-package-dir = prefix install
--with-package-{include,lib}dir = non-prefix type of package

And then we'd have less ambiguity. Packages such as MKL are already
exceptions to whatever is defined currently, so there'd be no more code to
add to handle this, i.e. MKL would remain an exception in the new model.

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

That's true.

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


apt-get only works because /usr/local is listed as a default search path.
Perhaps gcc should have been configured to add its own prefix but that
would have to be an issue taken up with each package manager.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120325/d20fd2b3/attachment.html>