search

eschnett / MPItrampoline

A forwarding MPI implementation that can use any other MPI implementation via an MPI ABI
MIT License
44 stars 4 forks source link

Allow overriding default compilation options #19

Closed ocaisa closed 2 years ago

ocaisa commented 2 years ago

Currently default compilation options are set during the build of MPItrampoline, it would probably be useful to be able to fully override these, e.g.,

exec ${MPITRAMPOLINE_CC:-@CMAKE_C_COMPILER@} ${CFLAGS:-"@CMAKE_C_FLAGS@"} -I@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_INCLUDEDIR@ @LINK_FLAGS@ -L@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_LIBDIR@ -Wl,-rpath,@CMAKE_INSTALL_PREFIX@/@CMAKE_INSTALL_LIBDIR@ "$@" -lmpi -ldl
ocaisa commented 2 years ago

OpenMPI seems to use it's own flags: https://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0

Perhaps there is a good reason for that...

eschnett commented 2 years ago

I'm generally not a fan of these wrappers. In the end, all they do is add a few flags to find include files and libraries. If that works, that's fine, but if this is getting in the way, then one should use MPI like any other library, either by managing these flags manually or by using pkgconfig. What if every library out there started to use wrappers like MPI instead of documenting the flags that need to be used?

The main reason I added these wrappers is that cmake requires it; it basically refuses to detect an MPI implementation unless such wrappers exist. cmake also requires very specific behaviour (undocumented, of course). And between cmake and Boost it's very difficult to write such wrappers.

Having said this, if there is a good use case I'd be happy to add more magic here. Since most other software doesn't know about MPItrampoline, and since MPItrampoline makes its wrappers behave like the OpenMPI wrappers (to make cmake and Boost happy), it might be worthwhile to support OpenMPI's environment variables as well.

But if you are designing the build system for a new software package, I highly recommend either using pkgconfig for MPI (and ignoring all the wrappers), or relying on cmake.

Does EasyBuild use these flags? What would simplify things the most for EasyBuild? Could one convince EasyBuild to treat MPI like any other library and use its pkgconfig or cmake config files (MPItrampoline.pc, MPItrampolineConfig.cmake)?

ocaisa commented 2 years ago

EasyBuild is aware of these flags and does set them, but that doesn't mean that it can't work without them.

The primary use case that comes to my mind is end users who are compiling code, mpicc hello_world.c "just works". Making learners know about all the other details is tedious (I've given quite a few courses in my time).

ocaisa commented 2 years ago

The real problem that I can imagine with the wrappers as they currently stand is that @CMAKE_C_FLAGS@ may contain options that may not be understood if one chooses another compiler via $MPITRAMPOLINE_CC and there is currently no way to override that (or in general they may contain unwanted values). I would have no problem if there were no such default flags at all but from your comment I am guessing there might be a reason they are there.

ocaisa commented 2 years ago

I'll open a PR and maybe we can discuss further there