[CMake] History and ideas behind FindMPI.cmake?

[Michael Wild]

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