|
5 | 5 | # Placeholder for external CMake definitions |
6 | 6 | # This directory will contain external dependencies. |
7 | 7 | # Use FetchContent or find_package to include them. |
8 | | -# Example: |
9 | | -# FetchContent_Declare( |
10 | | -# googletest |
11 | | -# GIT_REPOSITORY https://github.com/google/googletest.git |
12 | | -# GIT_TAG release-1.10.0 |
13 | | -# ) |
14 | | -# FetchContent_MakeAvailable(googletest) |
| 8 | + |
| 9 | +# Option to include FABM |
| 10 | +option(USE_FABM "Include FABM (Framework for Aquatic Biogeochemical Models)" ON) |
| 11 | + |
| 12 | +if(USE_FABM) |
| 13 | + include(FetchContent) |
| 14 | + |
| 15 | + FetchContent_Declare( |
| 16 | + fabm |
| 17 | + GIT_REPOSITORY https://github.com/fabm-model/fabm.git |
| 18 | + GIT_TAG v2.1.5 # Latest release as of 2024-03-15 |
| 19 | + ) |
| 20 | + |
| 21 | + # Note: FABM uses a custom variable FABM_SOURCE_DIR for its source directory |
| 22 | + # and FABM_BINARY_DIR for its build directory. |
| 23 | + # FetchContent_MakeAvailable will define fabm_SOURCE_DIR and fabm_BINARY_DIR. |
| 24 | + # We might need to set the FABM_SOURCE_DIR and FABM_BINARY_DIR to the values |
| 25 | + # used in the original Make build if FABM's CMake scripts rely on these exact names. |
| 26 | + # However, standard FetchContent practice is to use <lowercasename>_SOURCE_DIR. |
| 27 | + # Let's try with the standard variables first. |
| 28 | + FetchContent_MakeAvailable(fabm) |
| 29 | + |
| 30 | + # The fabm.mk file mentions MOSSCO_FABM_BINARY_DIR and MOSSCO_FABM_PREFIX. |
| 31 | + # If FABM's CMake build system doesn't pick up standard CMake variables |
| 32 | + # (like CMAKE_INSTALL_PREFIX for prefix or relying on its own build tree for binaries), |
| 33 | + # we might need to pass options during the add_subdirectory call implicitly done by |
| 34 | + # FetchContent_MakeAvailable, or set variables before it. |
| 35 | + # For now, assume FABM's CMakeLists.txt is well-behaved. |
| 36 | + |
| 37 | + # No explicit add_subdirectory(fabm) is needed here as FetchContent_MakeAvailable does that. |
| 38 | + # If FABM requires specific CMake variables to be set before its CMakeLists.txt is processed, |
| 39 | + # those would need to be set before FetchContent_MakeAvailable or passed via |
| 40 | + # CMAKE_ARGS to FetchContent_Declare. |
| 41 | + # For example, if FABM needed a specific install prefix: |
| 42 | + # set(FABM_PREFIX ${CMAKE_BINARY_DIR}/fabm_install CACHE PATH "FABM install prefix") |
| 43 | + # list(APPEND CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${FABM_PREFIX}) |
| 44 | + # And then use CMAKE_ARGS in FetchContent_Declare. |
| 45 | + # The fabm.mk mentions FABM_PREFIX and MOSSCO_FABM_BINARY_DIR. |
| 46 | + # Let's assume FABM's own CMake handles its build and output directories correctly for now. |
| 47 | +endif() |
| 48 | + |
| 49 | +# Option to include GOTM |
| 50 | +option(USE_GOTM "Include GOTM (General Ocean Turbulence Model)" ON) |
| 51 | + |
| 52 | +if(USE_GOTM) |
| 53 | + # Ensure FetchContent is included (it might have been included by FABM already) |
| 54 | + include(FetchContent) |
| 55 | + |
| 56 | + FetchContent_Declare( |
| 57 | + gotm |
| 58 | + GIT_REPOSITORY https://github.com/gotm-model/gotm.git |
| 59 | + GIT_TAG 7de74f # Specific commit from gotm.mk |
| 60 | + GIT_SUBMODULES_RECURSE TRUE # Initialize and update submodules like extern/flexout |
| 61 | + # For older CMake versions, GIT_SUBMODULES might be needed. |
| 62 | + # Using GIT_SUBMODULES_RECURSE to match `git submodule update --recursive` |
| 63 | + ) |
| 64 | + |
| 65 | + # Similar to FABM, FetchContent_MakeAvailable will define gotm_SOURCE_DIR and gotm_BINARY_DIR. |
| 66 | + # The gotm.mk file mentions external_GOTMDIR, GOTM_BINARY_DIR, and GOTM_PREFIX. |
| 67 | + # We assume GOTM's CMakeLists.txt handles its build and installation correctly. |
| 68 | + FetchContent_MakeAvailable(gotm) |
| 69 | + |
| 70 | + # If GOTM requires specific CMake variables to be set (e.g. for Fortran compiler flags, |
| 71 | + # paths, etc.), they would be set here before FetchContent_MakeAvailable or passed |
| 72 | + # via CMAKE_ARGS. The gotm.mk doesn't show specific build options being passed, |
| 73 | + # mostly git operations and directory setup. |
| 74 | +endif() |
| 75 | + |
| 76 | +# Option to include GETM |
| 77 | +option(USE_GETM "Include GETM (General Estuarine Transport Model)" ON) |
| 78 | + |
| 79 | +if(USE_GETM) |
| 80 | + # Ensure FetchContent is included |
| 81 | + include(FetchContent) |
| 82 | + |
| 83 | + # NOTE: The subtask specified https://github.com/getm-model/getm.git, but this URL |
| 84 | + # returned a 404 error. The original getm.mk uses git://git.code.sf.net/p/getm/code |
| 85 | + # (or https://git.code.sf.net/p/getm/code). |
| 86 | + # Proceeding with the SourceForge URL and 'iow' branch from getm.mk. |
| 87 | + FetchContent_Declare( |
| 88 | + getm |
| 89 | + GIT_REPOSITORY https://git.code.sf.net/p/getm/code.git # Using .git suffix, common for HTTPS git |
| 90 | + GIT_TAG iow # Specific branch from getm.mk |
| 91 | + # No GIT_SUBMODULES specified as getm.mk does not show submodule commands for GETM. |
| 92 | + ) |
| 93 | + |
| 94 | + # Similar to FABM and GOTM, FetchContent_MakeAvailable will define getm_SOURCE_DIR and getm_BINARY_DIR. |
| 95 | + # The getm.mk file mentions external_GETMDIR. |
| 96 | + # We assume GETM's CMakeLists.txt (if it has one) handles its build correctly. |
| 97 | + # The getm.mk command `$(MAKE) -C $(external_GETMDIR) distclean` suggests GETM might |
| 98 | + # use its own Makefile system. If GETM does not have a CMakeLists.txt at its root, |
| 99 | + # FetchContent_MakeAvailable (which implies add_subdirectory) might fail or not work as expected. |
| 100 | + # This might require using ExternalProject_Add instead. For now, following subtask's |
| 101 | + # implication of using add_subdirectory. |
| 102 | + FetchContent_MakeAvailable(getm) |
| 103 | + |
| 104 | + # If GETM requires specific CMake variables, they would be set here. |
| 105 | + # The getm.mk does not show specific build options beyond directory setup and its own make clean. |
| 106 | +endif() |
| 107 | + |
| 108 | +# Option to include EROSED |
| 109 | +option(USE_EROSED "Include EROSED (Handles sediment processes)" ON) |
| 110 | + |
| 111 | +if(USE_EROSED) |
| 112 | + include(ExternalProject) |
| 113 | + |
| 114 | + # Define the source directory for EROSED. This is where ExternalProject will download it. |
| 115 | + set(EROSED_EP_SOURCE_DIR ${CMAKE_BINARY_DIR}/erosed-src) |
| 116 | + set(EROSED_EP_BINARY_DIR ${CMAKE_BINARY_DIR}/erosed-build) # Build dir for EP, even if no actual build |
| 117 | + |
| 118 | + # Define paths that the main project can use. These will point inside EROSED_EP_SOURCE_DIR |
| 119 | + # These are set at CMake configure time, but files will only exist at build time |
| 120 | + # after the EROSED_ep target has run. |
| 121 | + set(EROSED_SOURCE_DIR ${EROSED_EP_SOURCE_DIR}/source CACHE INTERNAL "Path to EROSED source files") |
| 122 | + set(EROSED_INCLUDE_DIR ${EROSED_EP_SOURCE_DIR}/include CACHE INTERNAL "Path to EROSED include files") |
| 123 | + # The modules directory might also be needed if it contains Fortran modules. |
| 124 | + set(EROSED_MODULES_DIR ${EROSED_EP_SOURCE_DIR}/modules CACHE INTERNAL "Path to EROSED modules files") |
| 125 | + |
| 126 | + # Add EROSED as an external project |
| 127 | + ExternalProject_Add(EROSED_ep # Suffix _ep to distinguish the ExternalProject target name |
| 128 | + PREFIX erosed-ep-prefix # Directory for EP temporary files, stamps, etc. |
| 129 | + SVN_REPOSITORY https://svn.oss.deltares.nl/repos/openearthtools/trunk/programs/SandMudBedModule/03_Fortran/example/example |
| 130 | + SVN_ARGS --depth=empty # Initial checkout with empty depth |
| 131 | + # SVN_TRUST_CERT TRUE # Add if SSL certificate issues arise with the SVN server |
| 132 | + |
| 133 | + SOURCE_DIR ${EROSED_EP_SOURCE_DIR} |
| 134 | + BINARY_DIR ${EROSED_EP_BINARY_DIR} |
| 135 | + |
| 136 | + # Custom steps to update subdirs and export files from Delft3D |
| 137 | + # The erosed_custom_steps.cmake script expects to be run from <SOURCE_DIR> |
| 138 | + PATCH_COMMAND ${CMAKE_COMMAND} -E echo "EROSED_ep: Running custom SVN steps" && |
| 139 | + ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_LIST_DIR}/erosed_custom_steps.cmake |
| 140 | + |
| 141 | + # EROSED is likely a collection of source files, no specific build system |
| 142 | + CONFIGURE_COMMAND "" |
| 143 | + BUILD_COMMAND "" |
| 144 | + INSTALL_COMMAND "" |
| 145 | + BUILD_BYPRODUCTS ${EROSED_SOURCE_DIR}/bedbc1993.f90 # Ensure patch command has run |
| 146 | + ${EROSED_SOURCE_DIR}/soursin_3d.f90 |
| 147 | + ${EROSED_SOURCE_DIR}/compbsskin.f90 |
| 148 | + ${EROSED_SOURCE_DIR}/mathconsts.f90 |
| 149 | + ${EROSED_INCLUDE_DIR} # Placeholder for include dir existence |
| 150 | + ${EROSED_MODULES_DIR} # Placeholder for modules dir existence |
| 151 | + |
| 152 | + # Ensure that the custom SVN commands are re-run if the script changes (optional but good practice) |
| 153 | + # This might require listing erosed_custom_steps.cmake as a dependency of the patch step, |
| 154 | + # ExternalProject doesn't directly support this for PATCH_COMMAND in older CMakes. |
| 155 | + # For simplicity, this is omitted, but for robustness, one might use UPDATE_COMMAND |
| 156 | + # or a more complex PATCH_COMMAND that checks script modification times. |
| 157 | + ) |
| 158 | + |
| 159 | + # Create an interface library or similar to represent EROSED's include/source dirs |
| 160 | + # This is just one way to propagate usage requirements. |
| 161 | + # However, since EROSED source files are likely compiled directly into MOSSCO targets, |
| 162 | + # the main MOSSCO CMakeLists.txt will use EROSED_SOURCE_DIR and EROSED_INCLUDE_DIR directly. |
| 163 | + # For now, just ensuring the directories are set is the main goal. |
| 164 | + # Adding a target that depends on EROSED_ep can ensure it's built. |
| 165 | + add_library(erosed_placeholder INTERFACE) |
| 166 | + add_dependencies(erosed_placeholder EROSED_ep) |
| 167 | + # target_include_directories(erosed_placeholder INTERFACE ${EROSED_INCLUDE_DIR} ${EROSED_MODULES_DIR}) |
| 168 | + # Sources would be added to the consuming target directly using ${EROSED_SOURCE_DIR}/*.f90 etc. |
| 169 | + |
| 170 | + message(STATUS "EROSED configured using ExternalProject_Add.") |
| 171 | + message(STATUS "EROSED source directory (available at build time): ${EROSED_SOURCE_DIR}") |
| 172 | + message(STATUS "EROSED include directory (available at build time): ${EROSED_INCLUDE_DIR}") |
| 173 | + message(STATUS "EROSED modules directory (available at build time): ${EROSED_MODULES_DIR}") |
| 174 | + |
| 175 | +endif() |
| 176 | + |
| 177 | +# Option to include JSON-Fortran |
| 178 | +option(USE_JSON_FORTRAN "Include JSON-Fortran library" ON) |
| 179 | + |
| 180 | +if(USE_JSON_FORTRAN) |
| 181 | + # Ensure FetchContent is included (might have been by previous dependencies) |
| 182 | + include(FetchContent) |
| 183 | + |
| 184 | + FetchContent_Declare( |
| 185 | + jsonfortran # Using a name that FetchContent_MakeAvailable will use for variables |
| 186 | + GIT_REPOSITORY https://github.com/jacobwilliams/json-fortran.git |
| 187 | + GIT_TAG 9.0.3 # Latest release as of March 2024 from GitHub page |
| 188 | + # Original Makefile clones default branch with depth 1. |
| 189 | + # Using a specific tag is better for reproducibility. |
| 190 | + ) |
| 191 | + |
| 192 | + # json-fortran is a well-behaved CMake project. |
| 193 | + # FetchContent_MakeAvailable will download, configure, and add it as a subdirectory. |
| 194 | + # It will create targets like jsonfortran::jsonfortran-static or jsonfortran::jsonfortran (shared). |
| 195 | + # The main MOSSCO build can then link against these. |
| 196 | + FetchContent_MakeAvailable(jsonfortran) |
| 197 | + |
| 198 | + message(STATUS "JSON-Fortran configured using FetchContent. Version: 9.0.3") |
| 199 | + # The actual targets (e.g., jsonfortran::jsonfortran-static) are made available by |
| 200 | + # json-fortran's own CMakeLists.txt when FetchContent_MakeAvailable is called. |
| 201 | + # The main project can link to these targets. |
| 202 | + # The main project can link to these targets. |
| 203 | +endif() |
| 204 | + |
| 205 | +# Option to include SQLite (from flibs-cvs, including Fortran wrapper) |
| 206 | +option(USE_SQLITE "Include SQLite library with Fortran wrapper (from flibs-cvs)" ON) |
| 207 | + |
| 208 | +if(USE_SQLITE) |
| 209 | + include(ExternalProject) # Ensure ExternalProject is included |
| 210 | + |
| 211 | + set(SQLITE_FLIBS_SOURCE_DIR ${CMAKE_BINARY_DIR}/flibs-cvs-sqlite-src) |
| 212 | + set(SQLITE_FLIBS_BUILD_DIR ${CMAKE_BINARY_DIR}/flibs-cvs-sqlite-build) # For build logs etc. |
| 213 | + set(SQLITE_FLIBS_INSTALL_LIB_DIR ${CMAKE_BINARY_DIR}/lib/sqlite_flibs) |
| 214 | + set(SQLITE_FLIBS_INSTALL_MOD_DIR ${CMAKE_BINARY_DIR}/modules/sqlite_flibs_fortran_mods) |
| 215 | + |
| 216 | + file(MAKE_DIRECTORY ${SQLITE_FLIBS_INSTALL_LIB_DIR}) |
| 217 | + file(MAKE_DIRECTORY ${SQLITE_FLIBS_INSTALL_MOD_DIR}) |
| 218 | + |
| 219 | + # Define output locations for CMake variables |
| 220 | + set(SQLITE_C_OBJECT_FILE ${SQLITE_FLIBS_INSTALL_LIB_DIR}/csqlite.o CACHE INTERNAL "Path to csqlite.o from flibs") |
| 221 | + set(SQLITE_Fortran_OBJECT_FILE ${SQLITE_FLIBS_INSTALL_LIB_DIR}/fsqlite.o CACHE INTERNAL "Path to fsqlite.o from flibs") |
| 222 | + set(SQLITE_Fortran_MODULE_DIR ${SQLITE_FLIBS_INSTALL_MOD_DIR} CACHE INTERNAL "Path to fsqlite fortran modules") |
| 223 | + # Set a global property that src/utilities/CMakeLists.txt can query |
| 224 | + set_property(GLOBAL PROPERTY MOSSCO_SQLITE_C_OBJECT_FILE ${SQLITE_C_OBJECT_FILE}) |
| 225 | + set_property(GLOBAL PROPERTY MOSSCO_SQLITE_Fortran_OBJECT_FILE ${SQLITE_Fortran_OBJECT_FILE}) |
| 226 | + set_property(GLOBAL PROPERTY MOSSCO_SQLITE_Fortran_MODULE_DIR ${SQLITE_Fortran_MODULE_DIR}) |
| 227 | + |
| 228 | + |
| 229 | + ExternalProject_Add(sqlite_flibs_ep |
| 230 | + PREFIX sqlite_flibs_ep_prefix |
| 231 | + CVS_REPOSITORY :pserver:anonymous@flibs.cvs.sourceforge.net:/cvsroot/flibs |
| 232 | + CVS_MODULE src/sqlite # Module to checkout |
| 233 | + # CVS_TAG # No specific tag mentioned in Makefiles, gets HEAD |
| 234 | + |
| 235 | + SOURCE_DIR ${SQLITE_FLIBS_SOURCE_DIR} |
| 236 | + BINARY_DIR ${SQLITE_FLIBS_BUILD_DIR} # Log dir for build, not building in-source |
| 237 | + |
| 238 | + # Uses the Makefile within flibs/src/sqlite |
| 239 | + CONFIGURE_COMMAND "" # No configure step mentioned |
| 240 | + BUILD_COMMAND $(MAKE) -C ${SQLITE_FLIBS_SOURCE_DIR} # Runs make in the checked-out sqlite dir |
| 241 | + INSTALL_COMMAND ${CMAKE_COMMAND} -E copy ${SQLITE_FLIBS_SOURCE_DIR}/fsqlite.o ${SQLITE_Fortran_OBJECT_FILE} && |
| 242 | + ${CMAKE_COMMAND} -E copy ${SQLITE_FLIBS_SOURCE_DIR}/csqlite.o ${SQLITE_C_OBJECT_FILE} && |
| 243 | + ${CMAKE_COMMAND} -E copy_if_different ${SQLITE_FLIBS_SOURCE_DIR}/*.mod ${SQLITE_Fortran_MODULE_DIR}/ |
| 244 | + # copy_if_different for .mod files as their names might be compiler dependent |
| 245 | + |
| 246 | + # Ensure these products are considered by dependent targets |
| 247 | + BUILD_BYPRODUCTS ${SQLITE_C_OBJECT_FILE} ${SQLITE_Fortran_OBJECT_FILE} |
| 248 | + # Add specific .mod file if name is known and stable, e.g. ${SQLITE_Fortran_MODULE_DIR}/fsqlite.mod |
| 249 | + # otherwise, the directory itself can be a byproduct if CMake supports it, or a stamp file. |
| 250 | + ) |
| 251 | + |
| 252 | + # Create an interface library to represent the compiled SQLite objects and module path |
| 253 | + add_library(sqlite_flibs INTERFACE) |
| 254 | + add_dependencies(sqlite_flibs sqlite_flibs_ep) # Ensures sqlite_flibs_ep builds before anything using sqlite_flibs |
| 255 | + # The actual object files SQLITE_C_OBJECT_FILE and SQLITE_Fortran_OBJECT_FILE |
| 256 | + # will be added to the mossco_db library target in src/utilities/CMakeLists.txt |
| 257 | + # The include path for modules is SQLITE_Fortran_MODULE_DIR |
| 258 | + target_include_directories(sqlite_flibs INTERFACE ${SQLITE_Fortran_MODULE_DIR}) |
| 259 | + # Add object files to the interface if that's how we want to propagate usage |
| 260 | + # target_sources(sqlite_flibs INTERFACE ${SQLITE_C_OBJECT_FILE} ${SQLITE_Fortran_OBJECT_FILE}) This is not standard for INTERFACE targets with objects. |
| 261 | + # Instead, src/utilities/CMakeLists.txt will directly use the OBJECT_FILE variables. |
| 262 | + |
| 263 | + message(STATUS "SQLite (from flibs-cvs) configured using ExternalProject_Add.") |
| 264 | + message(STATUS "SQLite C object file (build time): ${SQLITE_C_OBJECT_FILE}") |
| 265 | + message(STATUS "SQLite Fortran object file (build time): ${SQLITE_Fortran_OBJECT_FILE}") |
| 266 | + message(STATUS "SQLite Fortran module dir (build time): ${SQLITE_Fortran_MODULE_DIR}") |
| 267 | + |
| 268 | +endif() |
0 commit comments