Use FMS build-in autotools-based build system, instead of building FMS from scratch in CMake #137
Comments
|
One thing to keep in mind is that we would like to move the FMS out of the models and make them a prerequisite, i.e. a library that can be linked to, similar to the NCEP libraries etc. This would be a good time to switch to the GFDL build system. @DusanJovic-NOAA @junwang-noaa how far are we wrt making this happen? |
|
OK, that's great. So instead of building it, we need a FindFMS() CMake function, to find it, and allow users to specify its location in the standard CMake way. |
That's right - once we make the move. For now I wouldn't change anything to keep things simple. |
|
Right now the develop branch seems to be broken for me due to FMS (#109). So that is simple, but not helpful. |
I think this is because the hotfixes from the public release branch have not been brought back to the develop branch, which needs to be done anyway. |
|
Do you see how this is not agile? |
|
OK, I will set this aside and wait for you guys to resolve it. I look forward to the day when this code is under CI, and we can be confident that the latest develop branch can build and run correctly. Believe me, you will enjoy this code a lot more when that is true, as will I. I will circle around to this build again next week and see where we are... Thanks for the info, it's very helpful to know that this doesn't work for other developers, rather than spending more time debugging it. |
@climbfuji We are working with GFDL on using pre-compiled FMS library. I have started testing that on Hera. Yes, once we make the switch, in the top level CMakeLists.txt the only thing you'll see is: However this will not solve the issue described here NOAA-GFDL/FMS#276 which is why develop branch is broken on systems with new glibc (ie. Ubuntu 20.04) |
|
OK, what I am reading in the GFDL issue is that this problem would be resolved by using the autotools build, which correctly checks for the symbol gettid. As a modern build system should. So the problem is not a GFDL bug, the problem is that we have an external build system which is not tracking the changes in the GFDL code. Nor, in general, would I expect us to be able to track all the changes in the FMS and keep the build system up to date. They must maintain their own build. And they do. Which takes us right back to the starting point. We should not be attempting to build FMS, we must use it's already existing build system. It's not clear why we would wait to solve this problem. |
|
Is there a branch where this fix exists yet? THis is holding me back from working on this code on my development workstation... |
This PR contains cleanup work to address wrong units and some issues raised in recently merged PRs: - correct units for latitude, longitude, and pi - correct standard name air_temperature_save_from_cumulus_paramterization to air_temperature_save_from_convective_parameterization - remove unused variables in two routines in `GFS_typedefs.F90` - remove recently introduced variable `cycling` (part of GFS_control DDT), now a local variable in `physics/module_MYNNPBL_wrapper.F90` - change order of interstitial schemes in `ccpp/suites/suite_FV3_GFS_2017_fv3wam.xml` to match other SDFs Fixes ufs-community#138 and parts of ufs-community#137.
|
Hi @edwardhartnett Does PR #441 address/solve this issue? |
Adds @middlecoff as a codeowner
Current we have the rules for building FMS in our top-level CMake file, but the code for FMS of course lives at GFDL and is managed there.
They have their own very excellent and well-maintained build system based on standard tools. Instead of attempting to reproduce this, we should use the existing build system, which tracks changes in their codes. (That is, if they add or remove a file or pre-processor symbol, they also change their build system to reflect that, so we don't have to.)
As GFDL moves further into better use of build systems it's going to be harder to keep up with them with an external build system, such as we now have.
Removing these build rules, and using the GFDL provided build, will eliminate problems like #109 and #114.
I've discussed this with @mark-a-potts and he agrees that we should use the GFDL-provided FMS build. There are other cases where we are launching autotools builds from CMake. It works fine.
The text was updated successfully, but these errors were encountered: