On Fri, 2010-02-26 at 11:21 +0100, Sylvestre Ledru wrote: > Le vendredi 26 février 2010 à 09:54 +0000, Alastair McKinstry a écrit : > > > > > Perhaps using pkg-config (an mpi.pc file) would be a better solution to > > this; it is more > > standard: the mpicc, etc. approach isn't very scalable, you can't wrap > > every complex > > library. Use mpi.pc to point to where includes, etc. are, and > > alternatives to change > > the mpi.pc between versions. You can then, if necessary, use > > dependencies and conflicts > > within the pkg-config mechanism if need be, which aren't available if > > you use mixed > > mpicc / gcc within Makefiles. > The problem with .pc is that a lambda user will consider that it is provided by OpenMPI or MPICH2 > and expect to find it on other distributions. Causing pkg-config to be > useless... I'm pretty sure OpenMPI upstream would welcome such a contribution, and I'd be surprised if MPICH2 upstream didn't as well, so I don't think that should limit us. Long-term this is my favorite solution, as other upstreams would likely also welcome patches to their configuration systems to use pkg-config to detect MPI, and if they don't, it's not that hard to maintain those patches. If we commit to this I'd gladly drop the other library and header alternatives symlinks -- with one constraint: pkg-config would need to point to libraries in /usr/lib so libtool doesn't add -rpath /usr/lib/openmpi/lib . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part