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.