CSM_share: no cime/Tools/Makefile #6025
Conversation
* master: Update CIME submodule Fix a few things I missed
|
|
Looks like there's also a CIME submodule change. Intended? |
|
@rljacob , good catch. That was not intended. |
CSM_share: no cime/Tools/Makefile The CSM_share build is very similar to how we build our main components, except it was being driven by the CIME/Tools/Makefile. This PR changes it to use our CMake build_model function. A few minor tweaks were needed, the main problem was with the Depends files. The CSM_share build cannot use our standard Depends system due to the likelihood that the Depends file will modify flags for files that CSM doesn't know about, which is currently an error. Instead, the CSM depends files are moved to E3SM/share, which is a bit unfortunate since it is not consistent and also makes them non-customizable within a case. On the plus side, this allows us to get rid of our last remaining Makefile-style Depends files. [BFB]
|
Wouldn't it be easier to make the CMakeLists.txt in It seems to me that by using build_model we're trying to use a cannon to kill a fly. |
|
@bartgol , that's an interesting thought. I think the current approach is probably the path of least resistance in that it gets us the exact behavior we had before (build_model.cmake was originally designed to mimic CIME/Tools/Makefile) with minimal additional lines of CMake. build_model is definitely overkill for csm_share (I'm not 100% sure no one is using sourcemods for these files though) but it has the advantage of code reuse. Your ideas are something that could be interesting for V3 of the build system. As a side note, V3 will probably be the hardest upgrade yet because it will involve diving in to those massive perl files to pull out things that CMake should be handling. |
There was a problem hiding this comment.
I agree this is the path of least resistance, so I'm going to approve. For what is worth though, I am in favor of doing the V3 effort. My reasoning is that yes, using CMake over Makefiles has the advantage of being more readable for new devs/users (less ppl fiddle with Makefile's these days), but if the underlying logic and (cmake) code flow is still the same (the Filepath trick to retrieve the src files is a great example), it remains hard to digest/read for those not accustomed to it.
|
@bartgol , thanks. V3 will come someday, hopefully a long time from now :) Those perl eam configure files are the stuff of nightmares. |
|
We still want to see those perl configs completely replaced with python (minus any cmake parts). No one seems motivated to do it. |
|
@rljacob , that would be a nice thing for E3SM. It will be a huge job: So that's nearly 12,000 lines of perl just for eam. My hunch is that there's a huge amount of copy/paste code design going on, so a well-implemented python port should be far smaller, but that's still a lot of perl to sift through. Maybe I will get around to it some day 🤷♂️ |
Is the plan for v4 to replace eam with eamxx? Or are both of them still going to be there. If eam is going away, then we can allow eam to maintain its logic, and just replace perl with cmake/python only for long-term components... |
|
ELM also has a long perl configure. |
|
Ok, but I would take 1 long perl over 2 long perls :) |
The CSM_share build is very similar to how we build our main components, except it was being driven by the CIME/Tools/Makefile. This PR changes it to use our CMake build_model function. A few minor tweaks were needed, the main problem was with the Depends files. The CSM_share build cannot use our standard Depends system due to the likelihood that the Depends file will modify flags for files that CSM doesn't know about, which is currently an error. Instead, the CSM depends files are moved to E3SM/share, which is a bit unfortunate since it is not consistent and also makes them non-customizable within a case. On the plus side, this allows us to get rid of our last remaining Makefile-style Depends files.
[BFB]