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.
Specific issues that I have are: 1) It does not really take advantage of MPI compiler wrappers like it should. The whole purpose of having an MPI compiler wrapper is to avoid having to explicitly match up the C/C++/Fortran compilers, get the compiler flags, and list the link libraries. Trying to match the raw C, C++, and Fortran compilers with the MPI compiler wrappers is asking for trouble and will result in subtle bugs. 2) It does not provide or differentiate C, C++, and Fortran compilers. It just specifies MPI_COMPILER. Is that a C or C++ compiler? This matter to many projects. 3) Getting MPI setup when it is in a non-standard location is very hard (or at least I have not figured out the easy way). 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. 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. 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? Does anyone else have similar frustrations with FindMPI.cmake and would like to see a new implementation as described above? How many CMake projects have a serious MPI component that use FindMPI.cmake? Cheers, - Ross
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
