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

Attachment: FindMPI.cmake
Description: Binary data




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:


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-705a4cda7...@llnl.gov>, Todd Gamblin
<tgamb...@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>

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to