[Ncep.list.fv3-announce] cmake fv3
dusan.jovic at noaa.gov
Mon May 15 14:48:26 UTC 2017
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:
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
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
More information about the Ncep.list.fv3-announce