Open olesenm opened 5 months ago
Thank you very much, @olesenm, for sharing your observations and suggestions. We'll look into each point you've raised as part of our next release due in the coming months.
You are absolutely correct that MUI operates as a C++ header-only code, independent of the MPI vendor and version. The only prerequisites are support for at least C++11 and the availability of a version of MPI. Currently, all wrappers (Fortran, C, and Python) need compilation to generate either static or dynamic libraries.
I will conduct experiments and implement your suggestions in due course.
General wishlist and/or misc notes. No immediate action (or any action) required.
looked a bit at the interface while trying to understand some integration code. From what I can see, in the non-fortran case and others the MUI code will be installed as a header only configuration. In this case, the header is in fact independent of the MPI vendor and version. So following snippet is actually irrelevant:
Not sure what exactly the conditions would be, but seems like having
might be able to change to this in that case:
Not really sure if the
"*.f90"
install pattern is relevant for non-fortran."config.h"
) have a very generic naming and may result in include conflicts with other packagescould be useful to have a MUI_VERSION define in the mui header. Would allow this type of code:
This would allow a nice separation of the regular detection defines and ones related to MUI itself (ie, is known and has a particular min API level). I would personally opt for a linear API number like boost (or OpenFOAM) since these are really easy to test for without needing extra macros. Eg