[CMake] FindMPI doesn't differentiate between languages

Todd Gamblin tgamblin at llnl.gov
Sun Dec 26 19:26:54 EST 2010


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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101226/64db37f8/attachment.htm>


More information about the CMake mailing list