Recently introduced CRTM cmake build breaks ufs-bundle
climbfuji opened this issue · 11 comments
Description
The recently introduced cmake build for crtm breaks ufs-bundle:
CMake Error at fv3-jedi/CMakeLists.txt:84 (find_package):
By not providing "Findcrtm.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "crtm", but
CMake did not find one.
Could not find a package configuration file provided by "crtm" (requested
version 2.2.3) with any of the following names:
crtmConfig.cmake
crtm-config.cmake
Add the installation prefix of "crtm" to CMAKE_PREFIX_PATH or set
"crtm_DIR" to a directory containing one of the above files. If "crtm"
provides a separate development package or SDK, be sure it has been
installed.
-- Configuring incomplete, errors occurred!
Additional information
Until this is resolved, use the Skylab v7 tag of CRTM (workaround is in #48).
Workaround was merged (use Skylab v7 release tag for CRTM). This is not a solution, therefore keeping this issue open.
@BenjaminTJohnson Unfortunately the update we merged into develop (install prefix fix) did not help - this is still an issue. Hopefully I have some time in the next few weeks!
I guess I'm confused, I haven't changed cmake related things for a while.
Should I revert the latest change?
No, sorry for the confusion. I was hoping the latest change would solve a problem that was introduced between the skylabv7 tag (still ecbuild) and the skylabv8 tag (cmake) of crtm. Looking at the error more closely, that was a fool's hope. It can't find crtmConfig.cmake / crtm-config.cmake.
@climbfuji JCSDA/CRTMv3#140 - I may have fixed this inadvertently, though I'm not a regular ufs-bundle user. Might be worth revisiting.
@shlyaeva @fmahebert @BenjaminTJohnson please see @rhoneyager-tomorrow 's message above
Thank you @rhoneyager-tomorrow and @climbfuji for bringing this up. I've just tried to build ufs-bundle with the crtmv3 develop and unfortunately see the same error as in this issue description.
@shlyaeva @climbfuji @rhoneyager-tomorrow I'm confused why CRTMv3 develop works with jedi-bundle: fv3-jedi is the same commit hash for both jedi-bundle and ufs-bundle. I rolled crtmv3 back to even prior to Ryan's commits, and ufs-bundle was failing before Ryan's commits, so this isn't a very new issue.
Specifically:
jedi-bundle: -- [fv3jedi] (1.9.0) [d3c800b]
ufs-bundle: -- [fv3jedi] (1.9.0) [d3c800b]
Any thoughts about what might be different between these two?
@shlyaeva @climbfuji @rhoneyager-tomorrow because I was bored during my PTO, I think I've narrowed this down to the following: I copied the following cmake material from jedi-bundle "a" to ufs-bundle "b" CMakeLists.txt, and it allows it to cmake to completion.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index d8643d6..7ca39fd 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,26 +11,40 @@ find_package( ecbuild 3.5 REQUIRED HINTS ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CUR
project( ufs-bundle VERSION 1.1.0 LANGUAGES C CXX Fortran )
-list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
+# Default release mode
+set( ECBUILD_DEFAULT_BUILD_TYPE Release )
-include( ecbuild_bundle )
-include( GNUInstallDirs )
-set(CMAKE_INSTALL_LIBDIR "lib")
+# Enable OpenMP and MPI
+set( ENABLE_MPI ON CACHE BOOL "Compile with MPI" )
+set( ENABLE_OMP ON CACHE BOOL "Compile with OpenMP" )
+# Depend path for non-ecbuild packages
set(DEPEND_LIB_ROOT ${CMAKE_CURRENT_BINARY_DIR}/Depends)
list(APPEND CMAKE_PREFIX_PATH ${DEPEND_LIB_ROOT})
-message("prefix path is ${CMAKE_PREFIX_PATH}")
-# Default release mode
-set( ECBUILD_DEFAULT_BUILD_TYPE Release )
+# Library path for non-ecbuild packages
+link_directories(${CMAKE_CURRENT_BINARY_DIR}/lib)
+
+include( GNUInstallDirs )
+if(APPLE)
+ list( APPEND CMAKE_INSTALL_RPATH $ENV{llvm_openmp_ROOT}/lib )
+endif()
+list( APPEND CMAKE_INSTALL_RPATH ${CMAKE_CURRENT_BINARY_DIR}/fv3 )
-# Enable MPI
-set( ENABLE_MPI ON CACHE BOOL "Compile with MPI")
-set( ENABLE_OMP ON CACHE BOOL "Compile with OpenMP")
+# add the automatically determined parts of the RPATH
+# which point to directories outside the build tree to the install RPATH
+set(CMAKE_INSTALL_RPATH_USE_LINK_PATH ON)
-# Use external jedi-cmake or build in bundle
+# when building, already use the install RPATH
+set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)
+
+# Define bundle
+ecbuild_bundle_initialize()
Not sure which of the above fixed it, but ufs-bundle was missing the ecbuild_bundle_initialize line, and the RPATH stuff -- which is the most likely culprit in my extremely limited experience with cmake. This is as far as my laziness will take me, but hopefully one of the 3 of you can spot the exact changes necessary to fix ufs-bundle. I'm of the opinion that the "setup" material in all of our bundles should be more similar than they currently are.
@BenjaminTJohnson great! do you mind opening the PR for that?
The issue is that the ufs-weather-model uses a plain cmake build that doesn't work well in an ecbuild system. I didn't make the original design choice to use an external project for ufs-weather-model. Instead, for the new fv3 dycore in jedi-bundle, I decided to go a different route (create an interface cmake file for it with the minimum settings necessary). I think the same would work for ufs-weather-model in ufs-bundle.