Open hiker opened 3 months ago
I was imagining the decorator pattern. (not to be confused with Python decorators which are a bit different)
In this approach the MPI class would accept a compiler to its constructor and would mutate inputs as they were passed through to that wrapped compiler. In this case it will always be called MpiCompiler
, or whatever.
There is the issue of arguments but I believe that is handled by a different issue.
Yes, I believe I mentioned decorator somewhere in the PR. Here how I have started (but as I've said, since there are quite a few functions to be passed through and therefore tested, I'll do this as a separate PR):
def __init__(self, compiler: Compiler,
name: str,
exec_name: Union[str, Path],
category: Category):
self._compiler = compiler
super().__init__(name, exec_name, ...)
...
def check_available(self) -> bool:
...
# If the wrapped compiler is not available, the wrapper can't work
if not self._compiler.check_available():
return False
# Otherwise use the base class to test if the wrapper is available.
return super().check_available()
This is work in progress, so things might change.
One of my biggest conceptual issues: can we encode the MPI version into the hash? OpenMPI's mpifort
has an option --showme:version
, which returns the MPI version. Intel MPI has -v
which prints information about the MPI verison (as opposed to --version
which prints the compiler version.
Also add Cray compiler. which are essentially compiler wrappers.
An MPI compiler wrapper should be independent of the underlying compiler (but obviously use the compiler specific flags).
Best approach seems to be dynamically add mpi wrapper: if compiler
X
exist, create an MPI wrapperMpiX
, which takes anX
instance and use the X-specific flags.The ToolRepository or ToolBox should check to only add MPI wrapper for compiler that exist(?)