[CMake] New FindMPI.cmake with multi-language support (was Re: FindMPI doesn't differentiate between languages)

[Todd Gamblin]

Hi all,

I'm attaching a new version of FindMPI.cmake.  I'd really like to get this code (or something like it) reviewed and integrated into next, so any help with testing, code reviewing, change suggestions, etc. would be much appreciated!

This version supports finding MPI for different languages separately, and incorporates some suggestions from the list.  In particular, I tried to check only for the languages specified using project(), by testing MPI_${lang}_COMPILER_WORKS before finding and interrogating a particular MPI compiler.

I attempted to be backward compatible by setting all the old ${lang}-less MPI_XXX variables to the C++ values (preferred) or C compilers (if C++ is not available).  I don't see a good way to allow the user to set the MPI_LIBRARY or MPI_COMPILER cache variables as before.  I'd have to decide whether the user meant C++ or C, and even if I pick one it wouldn't be the same functionality as the prior FindMPI.  I claim this is good, because the prior version was ambiguous, but if people relied on these cache variables they might need to reconfigure to use the new version.  That said, I *DO* export all the old variables, so no modifications to CMakeLists.txt files should be necessary to use this in an existing project.  I dropped it into my own MPI project and it works fine.

Because they're awkward and ambiguous, I've done away with the old MPI_LIBRARY and MPI_EXTRA_LIBRARY as cache variables (though, again, they're still set).   Users can set MPI_<lang>_LIBRARIES and MPI_<lang>_COMPILER now, where they would've set MPI_LIBRARY and MPI_COMPILER before.  Same goes for MPI_INCLUDE_PATH.

One question that arose while writing this: why _MPI_PACKAGE_DIR unused?  Am I missing something?  It doesn't look like it's provided to any of the find commands in the main branch.  I left it that way in my version, but it seems like you really need that list of paths to find anything on Windows, as it contains all the MS HPC SDK paths.

I've superficially tested this version on my Mac, an intel cluster, and the Intrepid BG/P at Argonne.  Let me know if you need additions/updates for your system.  Testing on windows machines would be very useful, too, since I really don't have access to a Windows cluster.

Thanks!
-Todd





On Dec 26, 2010, at 4:26 PM, Todd Gamblin wrote:

> Thanks for the suggestions, everyone.  I'm finally taking a look at fixing FindMPI.
> 
> So far, I've added a couple extra interrogations to look for -compile-info and -link-info on newer versions of mvapich, and I'm finally getting around to figuring out what variables need to be set.
> 
> I intend to separate the compiler interrogation part of the script out into a function, so I can call it for per-language compilers.  I've actually already done something like this for autoconf.  I think the final version will end up structured something like that; here's the m4 if you're interested:
> 
> 	https://github.com/tgamblin/libra/blob/master/m4/lx_find_mpi.m4
> 
> Ok, now the details.  Here are variables set by the current version of FindMPI:
> 
> MPI_FOUND
> MPI_COMPILER
> MPI_COMPILE_FLAGS
> MPI_INCLUDE_PATH
> MPI_LINK_FLAGS
> MPI_LIBRARY
> MPI_EXTRA_LIBRARY
> MPI_LIBRARIES
> MPIEXEC
> MPIEXEC_NUMPROC_FLAG
> MPIEXEC_PREFLAGS
> MPIEXEC_POSTFLAGS
> 
> Observations and questions:
> 
> 1. For supporting multiple languages, the MPIEXEC flags shouldn't need to change, so I'll leave those as they are.  Correct me if I'm wrong.
> 
> 2. Instead of searching just for MPI_COMPILER, I'm going to search for MPI_C_COMPILER, MPI_CXX_COMPILER, and MPI_Fortran_COMPILER, then interrogate each separately.  I guess I'll set MPI_COMPILER to the CXX compiler if that was found, and the C compiler if not, and leave it unset if neither were found.  I believe this should take care of any backward compatibility issues.
> 
> 3. How is the "Fortran" language handled in CMake?  What version of Fortran are all the other variables labeled "Fortran" supposed to represent?  Should the MPI_Fortran_COMPILER search look for F95 compilers, then F90, then F77?  Or should F77 and F90 be separate?  If they're separate, how do you do this?
> 
> 4. MPI_FOUND, MPI_COMPILER, MPI_COMPILE_FLAGS, MPI_INCLUDE_PATH, MPI_LINK_FLAGS, MPI_LIBRARIES, MPI_EXTRA_LIBRARY, and MPI_LIBRARY will become MPI_<LANG>_FOUND, MPI_<LANG>_COMPILER, etc.
> 
> 5. What is the point of having MPI_LIBRARIES, MPI_LIBRARY and MPI_EXTRA_LIBRARY?  The latter two seem completely unnecessary.  Are there even builds that check for these, or that try to link against *just* MPI_LIBRARY?  What am I missing?  I suppose I need to keep these for backward compatibility, but I'd love to rewrite the interrogation part so that it just sets MPI_LIBRARIES, then I could parse that later to set the other two for backward compatibility.
> 
> Thoughts?  Answers and suggestions would be much appreciated.
> 
> Thanks!
> -Todd
> 
> 
> 
> 
> 
> 
> 
> 
> On Dec 20, 2010, at 6:09 AM, Marcel Loose wrote:
> 
>>>>> On 19-12-2010 at 0:04, in message
>> <A43E19D1-AF96-4935-99FD-705A4CDA7E34 at llnl.gov>, Todd Gamblin
>> <tgamblin at llnl.gov> wrote: 
>>> Hey all,
>>> 
>>> This has been brought up before (sort of) here:
>>> 
>>> 
>> 	http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/26533
>>> 
>>> FindMPI doesn't currently give you the libraries, includes, etc. for
>> 
>>> different languages. MPI compilers can (and typically do) have
>> different 
>>> includes/libraries depending on the language you're using.  It was
>> noted 
>>> above that you don't get the fortran libraries for MPI using the
>> current 
>>> macro.  Another problem with the current setup is that you're also
>> likely to 
>>> inadvertently get the C++ includes with the current FindMPI, unless
>> you 
>>> explicitly disable them using things like -DOMPI_SKIP_MPICXX.  This
>> can get 
>>> you unwanted C++ symbols in your MPI libraries (because the MPI C++
>> interface 
>>> and headers suck, but that's a whole different story).
>>> 
>>> I'd be interested in fixing this.  But I would like guidance on how
>> to do 
>>> it.  My inclination would be to make a new version that gives you not
>> just 
>>> MPI_FOUND, MPI_LIBRARIES, etc.. but MPI_<LANG>_FOUND,
>> MPI_<LANG>_LIBRARIES, 
>>> MPI_<LANG>_INCLUDE_PATH, etc.  If you read the thread above, someone
>> suggested 
>>> using components for this back in January, but that was left on the
>> table and 
>>> seems not to have been implemented.
>>> 
>>> What's the best way to implement proper language support in the
>> FindMPI 
>>> module?
>>> 
>>> -Todd
>> 
>> Hi Todd,
>> 
>> I think this is a good idea. You might consider taking into account
>> which languages are currently enabled, either explicitly with
>> enable_language() or implicitly with project().
>> 
>> Best regards,
>> Marcel Loose.
>> 
>> 
>> 
>> -- 
>> Marcel Loose
>> Senior Software Engineer, Computing Group R&D, Astron, the Netherlands
>> 
> 
> <ATT00001..txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101227/0fc0defc/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindMPI.cmake
Type: application/octet-stream
Size: 22417 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101227/0fc0defc/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101227/0fc0defc/attachment-0003.htm>