[Pkg-openmpi-maintainers] Bug#457088: Bug#457088: Bug#457088: mpi.h is missing

[Manuel Prinz]

Hi Ondrej!

Am Mittwoch, den 19.12.2007, 22:15 +0100 schrieb Ondrej Certik:
> Unfortunately I still don't understand how it works. I admit
> it can be my fault.

No problem. I'll try to explain the situation and reasoning below.

> Let me repeat my question:
> 
> Why does openmpi use /usr/lib instead of /usr/include? Other libraries
> use /usr/include, like petsc (/usr/include/petsc), libmesh
> (/usr/include/libmesh), gtk
> (/usr/include/gtk-2.0) etc. etc. Usually, as I understand it, they
> also use /usr/lib/something/include, but they always link from
> /usr/include.

I guess there's some misunderstanding here. mpi.h is located
in /usr/lib/openmpi/include so it does not conflict with other MPI
packages. But this directory is symlinked to /usr/include/mpi via
alternatives, along with the compilers. So this ensures that the mpicc
you use matches the /usr/include/mpi/mpi.h that is used and therefore
prohibits conflicts. This is true for all MPI packages that provide
mpi.h and mpicc (and similar compiler wrappers). So
including /usr/include/mpi in your include file search path is the right
thing to do. Given that, it does not matter if your package compiles for
example against openmpi or lam4.

> Also, I, as a user, was used to using /usr/include (/something) for
> everything, that's why I thought it'd the de facto standard, isn't it?
> And if not, is there some policy for that? I only found links I posted above,
> suggesting to use /usr/include.

You're right, /usr/include is still the search path. To the best of my
knowledge the current behavior is in agreement with policy since we
provide mpi.h under /usr/include. It's just in the mpi sub-directory to
not get in conflict with other MPI packages. (MPI should be MPI, right?)

Unfortunately, dpkg and other tools that can scan for files in packages
are not aware of symlinks created by update-alternatives. So you just
might have missed /usr/include/mpi.

Hope I was able to clarify the issue. And I don't think it's a bug as
well.

Best regards
Manuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-openmpi-maintainers/attachments/20071220/6abbc5a7/attachment-0003.pgp