-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CMake build to WW3 #533
Add CMake build to WW3 #533
Conversation
…all, and conflicts
knint is not portable and the generic routine nint should be used instead
…o properly pass them from CMake
model/src/CMakeLists.txt
Outdated
math(EXPR len "${len} - 1") | ||
|
||
# Loop over switch categories | ||
set(switch_files "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a clever solution to a complex problem, but I suspect the problem is more complex than it needs to be. It's unlikely that all these compiler switches are really needed. Most packages get by without anything like this level of complexity of build switches.
I would suggest that the coding team not get too comfortable with the JSON solution, and instead seek to reduce the number of switches to a manageable level (less than 5 or 6), and then handle them in the usual way in CMake. This will take some time, no doubt.
In the meantime, there should be very strict review of attempts to add more switches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough @edwardhartnett but we need to be able to compile the code as it is now, in all its complexity. The solution @kgerheiser came up with is greatly appreciated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree @edwardhartnett. It's a very unusual build with a lot of complexity, but I didn't want to touch any code, and let the build compile as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I totally agree that @kgerheiser cannot resolve these issues, and the build has to cope with them right now. His solution is elegant.
It's an unfortunate side effect of Kyle's clever solution that it's now easier than ever for the development team to add new switches. However, as we have seen, switches cause build system complexity and test difficulties. Better that if-statements are used in the code then #ifdef in the pre-processor, except for certainly well-understood cases, like whether or not a library is present at build-time.
@JessicaMeixner-NOAA perhaps you should consider some overall configuration namelist that can be read at application startup and can carry the switch settings for those switches that can be handled by code, instead of by the build.
Ideally, at some future point, Kyle's JSON solution could be removed, and the remaining switches handled by CMake command line switches, in the typical manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the switch file has become a proxy to create multiple combinations of possibilities within the wave model without a review of it being needed or not. The wave model will have to carry out a longer term refactoring/restrategizing on reducing the number of switch options. That will probably take a while :)
@mickaelaccensi my develop was out of date. Do a |
@mickaelaccensi you moved the prep.sh files in ww3_tp2.14 in different directories and both this branch and PR changed them. Do we just need to move the prep.sh in this branch to the new locations? Or are there some of the changes you made that also need to be included, etc? |
ok I'm solving the conflicts then I try to make a PR |
@kgerheiser , I still can't make a PR on your github branch. It seems your visibility is not fully public for PR or contribution... |
@mickaelaccensi I'm not sure what that's about. I added you as a collaborator on the repo. |
|
But @kgerheiser made changes to prep_env.sh to work with cmake. Then you also changed the file itself + changed its locations. I don't know if I should just take the prep_evn.sh in this branch and move it to each of the files or if there needs to be some sort of changes. If you can tell me that I can make the changes, but I don't know the answer to this question to do it myself. |
it works ! thanks |
…o feature/cmake
Updates for merging tp2.14 updates from develop branch
@kgerheiser I'm starting the final set of regression tests for this and hope to post the results at the end of today and then be able to merge this tomorrow. If there is any needed updates to the PR description, we should do those today. |
When comparing this branch to itself, we get the following diff:
Full matrix: |
When comparing this branch to develop,
The diffs in tp2.5 are "good" diffs:
in which we get a 0 instead of -2147483648. The tp2.14 tests are likely because a different flag is used in compilation, but we get the same answers on those tests moving forward, so this seems likely okay. The matrixDiff.txt file will not upload for whatever reason. |
When the matrixDiff is very large, github does not allow you to upload it. |
@aliabdolali good to know. I'm happy to post any portion of the matrixdiff if anyone is curious. |
fix matrix.comp
thanks @kgerheiser for this great development. |
hurrah !!!!!!! |
Good work @kgerheiser , this was a lot more complex than I anticipated! |
CMake provides a portable and standardized build system and out-of-source builds. This means a faster and simpler build system. See README for more documentation.
Pull Request Summary
PR to add a CMake build to WW3
See documentation here
Description
The CMake build handles the build a bit differently than the current build. It builds all available files/executables it can.
The build starts with a base set of files that have no dependencies (see https://github.com/kgerheiser/WW3/blob/feature/cmake/model/src/cmake/src_list.cmake) and then based on switches adds more files to the library (i.e. SCRIP, SCRIPNC, etc). It builds up a
ww3_lib
library and then links each executable to that library.The switch file options been extracted from the build system into
model/bin/switches.json
, which CMake parses at build time to check for necessary files/conflicts. This is meant to be a self-documenting way to add switches. Any new switches only have to be updated in this one location.See: https://github.com/kgerheiser/WW3/blob/feature/cmake/model/bin/switches.json
Each category is an element in the JSON array which contains a name, description, type, and an array of valid options.
Each valid option object can contain an array build files associated with the given switch. It also has an optional
requires
andconflicts
member to handle conflicting required and conflicting switches. Elements inrequires:
can be either a string or an array. If a string then that switch is required, if an array then one of those elements is required.To build:
The build type can be set with
-DCMAKE_BUILD_TYPE=<type>
where type can beDebug
orRelease
(case-sensitive)Based on the switches
This will put all executables in the install directory under
bin
and the library inlib
.Issue(s) addressed
Fixes #139
Check list
Yes
Please list appropriate labels code managers should add for this PR:
documentation, enhancement, new feature, ..
Reviewers: @mentions of suggested reviewers of the proposed changes
@JessicaMeixner-NOAA
Commit Message
Add a CMake build to WW3
CMake provides a portable and standardized build system and out-of-source builds. This means a faster and simpler build system. See README for more documentation.
Testing
Testing has been done on Hera and Datarmor, and the build contains a Github Actions build to test on each PR/Push.