You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't see a good use case that anyone would want to use a non-compiler as linker. So by making Linker a compiler wrapper we enforce that each linker is a compiler (and that we can always add compiler flags like openmp, ... to the link flags automatically).
Important additional requirement:
Similar to the way compiler wrapper reuse flags of a compiler, we need the same feature for linker.
Use case: A non-MPI version might use gfortran as linker, so a user would specify all flags for gfortran. But if we then want to link with mpif90-gfortran, we need to specify the same flags again. It would be much more useful if the linker-mpif90-gfortran could inherit flags from linker-gfortran. Not sure atm how to do this best, but the decorator pattern might just work - a linker could be be using another linker-compiler-wrapper etc.
Additionally, it must then also be able to overwrite them! E.g. one infrastructure library comes in a MPI and non-MPI version (with slightly different names). So linker-gfortran would link dl_esm_inf using the non-mpi version of the lib, but linker-mpif90-gfortran would instead link the MPI-enabled version. If we stick with this pattern, a compiler wrapper would need to collect all library settings 'underneath' (which is only available if the wrapped tools is another linker, and not the compiler), but then update any settings with its own.
Am happy to discuss
The text was updated successfully, but these errors were encountered:
I can't see a good use case that anyone would want to use a non-compiler as linker. So by making Linker a compiler wrapper we enforce that each linker is a compiler (and that we can always add compiler flags like openmp, ... to the link flags automatically).
Important additional requirement:
Similar to the way compiler wrapper reuse flags of a compiler, we need the same feature for linker.
Use case: A non-MPI version might use gfortran as linker, so a user would specify all flags for gfortran. But if we then want to link with mpif90-gfortran, we need to specify the same flags again. It would be much more useful if the linker-mpif90-gfortran could inherit flags from linker-gfortran. Not sure atm how to do this best, but the decorator pattern might just work - a linker could be be using another linker-compiler-wrapper etc.
Additionally, it must then also be able to overwrite them! E.g. one infrastructure library comes in a MPI and non-MPI version (with slightly different names). So linker-gfortran would link dl_esm_inf using the non-mpi version of the lib, but linker-mpif90-gfortran would instead link the MPI-enabled version. If we stick with this pattern, a compiler wrapper would need to collect all library settings 'underneath' (which is only available if the wrapped tools is another linker, and not the compiler), but then update any settings with its own.
Am happy to discuss
The text was updated successfully, but these errors were encountered: