On 12. Jan, 2009, at 23:02, Bartlett, Roscoe A wrote:
Hello,
What is the origin of the current FindMPI.cmake module? I am not
very happy with this module and I don't even fully understand why is
was written the way that it is.
I agree, it is not very robust. But I'd like to point out a few things:
I am seriously considering completely writing our own version of
FindMPI.cmake for Trilinos (called FindTPLMPI.cmake). The major
features of a new MPI find module would be:
1) It will differentiate C, C++, and Fortran MPI compilers
2) It will keep the MPI compilers intact and not try to extract out
compile options and MPI libraries.
3) The MPI compilers will automatically be set as
CMAKE_[C,CXX,Fortran]_COMPILER *before* the languages are enabled
and the compilers are checked. This will make sure that every bit
of code is built and linked in a consistent way (including during
the various configure-time checks). The trouble that you might have
is with try_run(...) commands and some MPI implementations that
require an explicit boot (like LAM MPI). Most MPI implementations
allow you to just run the executable without mpirun or mpiexec and
it will run correctly for a single process.
I consider this to be a "buggy" idea. It would be impossible to have a
project which builds both normal and MPI executables. I would probably
prefer a target property called "MPI" which can be set to TRUE if one
wants to compile a specific target with MPI.
4) The standard MPI install structure of many MPI implementations
(e.g. MPICH, OpenMPI, LAM MPI etc.) of prefix/[include, bin] will be
exploited and searching from MPI_BASE_DIR (which is set by the
client) will be done. In this way, you can just set a single cache
variable on most systems and get MPI totally set up.
This won't work at all. See the --includedir and --libdir options of
the OpenMPI configure script. Your proposal will force these values to
the default, making too many assumptions.
These days, I don't know if anyone still uses raw compilers and then
tries to manually pass in the compiler options and link libraries.
We can still support such a thing but I think this is the 1%
exception instead of the rule. Am I wrong about this?
I know of at least one large project which does not use the wrappers
because the developers abstracted the communications into separate
libraries, one for MPI, one for GAMMA and one for LVM. The user has
then the choice of which library should be used when he starts the
program. Couldn't do that with your proposal.
Michael
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
