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
option(BUILD_SHARED_LIBS"Build using shared libraries"OFF) # cmake-internal switch to toggle if library targets are being build as STATIC or SHARED, see https://cmake.org/cmake/help/latest/guide/tutorial/Selecting%20Static%20or%20Shared%20Libraries.html
set(TOPLEVEL_DIR ${CMAKE_CURRENT_LIST_DIR})
set(FESOM_COUPLED OFFCACHEBOOL"compile fesom standalone or with oasis support (i.e. coupled)")
set(OIFS_COUPLED OFFCACHEBOOL"compile fesom coupled to OpenIFS. (Also needs FESOM_COUPLED to work)")
set(CRAY OFFCACHEBOOL"compile with cray ftn")
set(USE_ICEPACK OFFCACHEBOOL"compile fesom with the Iceapck modules for sea ice column physics.")
set(OPENMP_REPRODUCIBLE OFFCACHEBOOL"serialize OpenMP loops that are critical for reproducible results")
that seems could be a nice way to consolidate all fesom specific build options into one file but then there are fesom specific options like ENABLE_OPENMP, others defined in src/CMakeLists.txt. This, apart from making main CMakeLists.txt somewhat irrelevant and makes one not to trust the options in it and one always has to check whats set in src/CMakeLists.txt.
I am finding it hard to take scattered machine specific options in src/CMakeLists.txt, for instance machine specific options exist based on FESOM_PLATFORM_STRATEGY for levante, albedo, aleph etc and are further split using ifs based on what compiler is used . It is not like if based on $FESOM_PLATFORM_STRATEGY is in one block if it can be at-times scattered at different locations. e.g,
env/machine/shell.xx seems to me a somewhat modular/elegant way to add a new machine with different compilers, this is currently just part of the story for building and running on that machine: one may need to add machine and compiler specific options in src/CMakelists.txt and at run time also change paths for input data for a machine in namelist.forcing,config even though we know we are on a specific machine paths are likely to be same, and find template job script from a different directory work. I wonder can this all be simplified by putting all relevant files for a particular machine in env. This also i think can reduce maintaining src/CMakeLists.txt (for example a machine reached EOL) and delegate burden of maintenance of machine specific options to users of the machine.
I think this needs to be thought of otherwise we make a mini RAPS, that may become a burden on developers and new comers.
This is to open a discussion on the issue and solutions.
The text was updated successfully, but these errors were encountered:
Consider the following points:
fesom2/CMakeLists.txt
Lines 13 to 19 in 21470c4
that seems could be a nice way to consolidate all fesom specific build options into one file but then there are fesom specific options like ENABLE_OPENMP, others defined in src/CMakeLists.txt. This, apart from making main CMakeLists.txt somewhat irrelevant and makes one not to trust the options in it and one always has to check whats set in src/CMakeLists.txt.
$FESOM_PLATFORM_STRATEGY
is in one block if it can be at-times scattered at different locations. e.g,fesom2/src/CMakeLists.txt
Lines 38 to 40 in 21470c4
fesom2/src/CMakeLists.txt
Lines 147 to 154 in 21470c4
work
. I wonder can this all be simplified by putting all relevant files for a particular machine in env. This also i think can reduce maintaining src/CMakeLists.txt (for example a machine reached EOL) and delegate burden of maintenance of machine specific options to users of the machine.I think this needs to be thought of otherwise we make a mini RAPS, that may become a burden on developers and new comers.
This is to open a discussion on the issue and solutions.
The text was updated successfully, but these errors were encountered: