hiker / fab_new

BOM version of the flexible build system for scientific software
https://metoffice.github.io/fab/
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

Refactor Linker tool to be a CompilerWrapper #20

Open hiker opened 1 month ago

hiker commented 1 month ago

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).

hiker commented 1 month ago

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