<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi all,</div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks!</div><div>-Todd</div><div><br></div><div></div></body></html>