In Dakota, MPI is detected before the packages sub-directory is included.
On one of our systems this results in MPI_FOUND being set in the external package hopspack while hopspack should be compiled without MPI support. hopspack uses the CMake variable mpi to enable MPI support, which sets MPI_FOUND and HAVE_MPI, if MPI support is requested. In my case HAVE_MPI is not set while MPI_FOUND is set from the outer scope.
(See hopspack/ConfigureMPI.cmake)
Therefore, hopspack tries to compile the MPI enabled cpp file with the serial hpp file.
Using HAVE_MPI instead of FOUND_MPI in hopspack/src/src-executor/CMakeLists.txt resolves the issue. So, consistently using HOPSPACK_HAVE_MPI similar to DAKOTA_HAVE_MPI instead of using multiple variables to control MPI support in hopspack could be a solution.
However, I haven't seen this issue before on other systems or in conda-forge/dakota-feedstock. So, it might be limited to my system.
In Dakota, MPI is detected before the packages sub-directory is included.
On one of our systems this results in
MPI_FOUNDbeing set in the external package hopspack while hopspack should be compiled without MPI support. hopspack uses the CMake variablempito enable MPI support, which setsMPI_FOUNDandHAVE_MPI, if MPI support is requested. In my caseHAVE_MPIis not set whileMPI_FOUNDis set from the outer scope. (See hopspack/ConfigureMPI.cmake)Unfortunately, hopspack uses
MPI_FOUNDto choose files for compilation: hopspack/src/src-executor/CMakeLists.txtBut the headers use
HAVE_MPI: hopspack/src/src-shared/HOPSPACK_GenProcComm.hppTherefore, hopspack tries to compile the MPI enabled cpp file with the serial hpp file.
Using
HAVE_MPIinstead ofFOUND_MPIin hopspack/src/src-executor/CMakeLists.txt resolves the issue. So, consistently usingHOPSPACK_HAVE_MPIsimilar toDAKOTA_HAVE_MPIinstead of using multiple variables to control MPI support in hopspack could be a solution.However, I haven't seen this issue before on other systems or in conda-forge/dakota-feedstock. So, it might be limited to my system.