[Ncep.list.fv3-announce] cmake fv3

Dusan Jovic dusan.jovic at noaa.gov
Mon May 15 14:48:26 UTC 2017


FV3 developers,

I have created a cmake based build system for the standalone fv3. 
Several people mentioned and/or suggested on more then one occasion that 
we switch from hand-written makefiles to some "modern" build system, so 
I created this as a proof-of-concept to see if it offers any real 
advantages compared to what we currently use.

My working copy of the trunk is:

/scratch4/NCEPDEV/meso/save/Dusan.Jovic/fv3/trunk_cmake

Please feel free to take a look and try it. Either run cmake directly or 
use compile script in the top-level directory. After going through this 
exercise I can say that I see, so far, only two maybe three advantages. 
Keep in mind that I have much more experience in gnu make then in cmake. 
I might be missing something very important here. As always, suggestions 
and constructive criticism are welcome. I'm sure some of you who are 
already using cmake can suggest many improvements.

First, cmake based build is usually done out-of-source which means you 
can run more then one build at the same time using different build 
options (for example 32-bit vs 64-bit build, or whatever). The second 
one is that cmake is using it's own Fortran module dependency resolution 
and does not rely on external tool, like mkDepends.pl. Some people might 
find that cmake configuration files (CMakeLists.txt) are cleaner then 
makefiles.

There are also some disadvantages. Cmake was designed to be cross 
platform makefile generation tool, and by cross platform I mean Linux, 
Windows, macOS, not wcoss, theia, jet or whatever linux platform we are 
building our code on. It provides many modules which help you find 
location of libraries not provided by operating system, like some gui 
libraries or networking libraries. There no available modules which will 
help you find and configure nceplibs or esmf. Which basically means that 
exactly the same information ( for example location of w3emc) must be 
provided in both gnumake and cmake system. ESMF provides only make 
snippet which can be included in gnu makefile but not in CMakeLists.txt. 
I had to manually specify location of include and module directories for 
esmf. Specifying location and names of all required esmf libraries is 
going to be even more difficult. I'm not sure how easy it's going to be 
to integrate cmake based build with the nems app builder or whatever we 
use currently. Then, the Fortran module dependency generation is not 
perfect. For example, it could not discover that fms/fft/fft.F90 depends 
on fft99.F90. Finally in the standard make I can do pretty much anything 
I want while in cmake if something is not supported by the cmake 
language it can be very difficult if not impossible to do something very 
specific. Maybe there are methods to run arbitrary shell scripts. If all 
you need is provided by cmake then you are fine, but if it's not it can 
be very challenging to implement. That's the main concern I have about 
cmake.

Dusan



More information about the Ncep.list.fv3-announce mailing list