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

[Dave Partyka]

This is very impressive Todd, :-)

I will forward you directions on how you can submit this for code review.
Also, I have a few projects we can test this with (VTK/ParaView), especially
on Windows. As for _MPI_PACKAGE_DIR, I believe this may just be left over
cruft that I thought I needed but ended up not being the case. The MS HPC
SDK installer always sets the system PATH to include mpiexec and MPICH2 is
found by registry entries.

On Mon, Dec 27, 2010 at 9:36 PM, Todd Gamblin <tgamblin at llnl.gov> wrote:

> 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>
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101227/81c66af2/attachment.htm>