CMAKE

[JessicaMeixner-NOAA]

There are various aspects of CMAKE that WW3 could look into using:

1. Add cmake build information to the WW3 repository (@flampouris )
2. Split the WW3 build into two parts, one that executes the switch pre-processing and two that generates the makefile dependencies. We could use cmake to execute the switch pre-processing and then to use cmake features to build our makefile dependencies (instead of the logic in make_makefile) which could speed things up for a single make (assuming cmake is much more efficient than we are). As suggested by @DusanJovic-NOAA
3. By using cmake as part of our build process, we would be adding the *.o files in different locations which could allow for parallel builds in the regression tests. This could be complicated by the fact that we reuse files for the different executables, but cmake may be able to handle that too (I am not an expert)?

[flampouris]

If anybody wants to test option 1, could check out WW3 from my repo.

[vkbo]

I just started working for the Norwegian Meteorological Institute, and have started looking at WW3. I have some experience setting up CMake for use with complex Fortran projects with custom and multiple pre-processors from my previous job. I could potentially help with this effort if my department gives me a go-ahead, although I haven't yet understood all the intricacies of the WW3 build chain.

Point 3 from the list above is doable, if I understand it correctly. CMake is fairly good at resolving Fortran dependencies and setting up a working build order. The dependencies for executables and libraries must of course be defined in the CMake file, but different build targets can have shared dependencies. CMake will sort out the order.

As for point 2, CMake can most likely also be used to parse switch files, and run the custom pre-processor thereafter. We did something similar in the previous project I worked on, up until we removed one of the custom pre-processors that depended on it, and switched to the standard c pre-processor. It does complicate the build process though, as the build steps have to be manually defined, but you can create lists to define which files to process how, and the lists can be auto-generated in various ways.

[aliabdolali]

Hi @vkbo
Thanks for stepping up and sharing your experiences, thoughts, etc
Please let us know if you made any progress in this matter or need help/explanation about the code.

[edwardhartnett]

We have just had a meeting in which we are discussing the CMake build system for WW3. @kgerheiser is putting the build together. From the meeting today:

• Switch files are used extensively throughout the test system (and perhaps the programmer community). They will be supported in the new build system.
• The new build cannot be considered complete until all existing testing runs with the new build.
• The cmake build will keep track of what code file need to be rebuilt. Manual tracking of code dependencies can end, and this information can live within the CMake files, as it does for other projects. As @vkbo notes, a well-designed cmake build is smart enough to build in parallel, and keep track of what needs to be rebuilt due to new switches.
• Testing for each PR is manually launched with the creation of a slurm script which runs on several HPC systems. Tests take hours to complete.