config/cmake: find MPI if the MPI component is requested

[mathstuf]

Otherwise projects using conduit::conduit_mpi may get errors about MPI::MPI_C not being a target without finding it themselves.

[cyrush]

We made a choice that folks can use a conduit built with MPI, downstream w/o using its MPI features w/o having to locate mpi.

We actually have tests that support this use case, one is our basic example of how to build conduit with cmake:

https://github.com/LLNL/conduit/blob/develop/src/examples/using-with-cmake/CMakeLists.txt

This means that downstream use must find MPI when using Conduit's MPI features.

The need to find mpi downstream is reflected in our using-with-cmake-mpi example:

conduit/src/examples/using-with-cmake-mpi/CMakeLists.txt

Line 65 in dffc5a6

if(NOT MPI_FOUND)

There are some other caveats about this: Even when MPI is on we may not search for it when it is implicitly supported by the compiler (cray use cases...)

This config var reveals if that is the case:

conduit/src/config/ConduitConfig.cmake.in

Line 49 in dffc5a6

set(CONDUIT_USE_CMAKE_MPI_TARGETS "@CONDUIT_USE_CMAKE_MPI_TARGETS@")

[mathstuf]

Can it be requested that Conduit does it via a component?

find_package(Conduit COMPONENTS MPI)?

[cyrush]

@mathstuf yes, that sounds like a much nicer way to formalize this

[mathstuf]

OK, I've added logic to handle components and then added support for the MPI component which takes the considerations you mentioned into account. I also updated the example to use the MPI component and bail if it isn't reported as being found. The example was also unconditionally using MPI::MPI_C which isn't correct when MPI is implicit in the toolchain (i.e., the targets aren't being used), so that is also removed.

[cyrush]

Awesome, thanks for adding the component based logic and updating the examples.

I have one question about the cmake config changes.