<div dir="ltr"><div><div><div><div><div><div>Dusan,<br><br></div>Thank you for doing this. It will be useful during the information gathering process of the NCEP Unified Workflow. <br><br></div>To answer some of your questions:<br><br></div>1. Shell process execution is done via the execute_process command. Is this what you were looking for?<br><br><a href="https://cmake.org/cmake/help/v3.0/command/execute_process.html">https://cmake.org/cmake/help/v3.0/command/execute_process.html</a><br><br></div>2. Obtaining variables from include-style makefiles (like <a href="http://esmf.mk">esmf.mk</a>) can be accomplished in a variety of ways. In essence, you make a temporary Makefile that "include <a href="http://esmf.mk">esmf.mk</a>" and then sends the variable to stdout.<br><br></div><div>I don't know how one would connect cmake to "module load" commands. My preference is not to do that. The modules should be loaded before cmake. Cmake's job is to adapt to the environment and build the program. Creating the environment should happen outside. <br><br></div><div>Mark Potts may be able to comment further, if he is on the FV3 list.<br></div><div><br></div>Sincerely,<br></div>Sam Trahan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 10:48 AM, Dusan Jovic <span dir="ltr"><<a href="mailto:dusan.jovic@noaa.gov" target="_blank">dusan.jovic@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FV3 developers,<br>
<br>
I have created a cmake based build system for the standalone fv3.<br>
Several people mentioned and/or suggested on more then one occasion that<br>
we switch from hand-written makefiles to some "modern" build system, so<br>
I created this as a proof-of-concept to see if it offers any real<br>
advantages compared to what we currently use.<br>
<br>
My working copy of the trunk is:<br>
<br>
/scratch4/NCEPDEV/meso/save/<wbr>Dusan.Jovic/fv3/trunk_cmake<br>
<br>
Please feel free to take a look and try it. Either run cmake directly or<br>
use compile script in the top-level directory. After going through this<br>
exercise I can say that I see, so far, only two maybe three advantages.<br>
Keep in mind that I have much more experience in gnu make then in cmake.<br>
I might be missing something very important here. As always, suggestions<br>
and constructive criticism are welcome. I'm sure some of you who are<br>
already using cmake can suggest many improvements.<br>
<br>
First, cmake based build is usually done out-of-source which means you<br>
can run more then one build at the same time using different build<br>
options (for example 32-bit vs 64-bit build, or whatever). The second<br>
one is that cmake is using it's own Fortran module dependency resolution<br>
and does not rely on external tool, like mkDepends.pl. Some people might<br>
find that cmake configuration files (CMakeLists.txt) are cleaner then<br>
makefiles.<br>
<br>
There are also some disadvantages. Cmake was designed to be cross<br>
platform makefile generation tool, and by cross platform I mean Linux,<br>
Windows, macOS, not wcoss, theia, jet or whatever linux platform we are<br>
building our code on. It provides many modules which help you find<br>
location of libraries not provided by operating system, like some gui<br>
libraries or networking libraries. There no available modules which will<br>
help you find and configure nceplibs or esmf. Which basically means that<br>
exactly the same information ( for example location of w3emc) must be<br>
provided in both gnumake and cmake system. ESMF provides only make<br>
snippet which can be included in gnu makefile but not in CMakeLists.txt.<br>
I had to manually specify location of include and module directories for<br>
esmf. Specifying location and names of all required esmf libraries is<br>
going to be even more difficult. I'm not sure how easy it's going to be<br>
to integrate cmake based build with the nems app builder or whatever we<br>
use currently. Then, the Fortran module dependency generation is not<br>
perfect. For example, it could not discover that fms/fft/fft.F90 depends<br>
on fft99.F90. Finally in the standard make I can do pretty much anything<br>
I want while in cmake if something is not supported by the cmake<br>
language it can be very difficult if not impossible to do something very<br>
specific. Maybe there are methods to run arbitrary shell scripts. If all<br>
you need is provided by cmake then you are fine, but if it's not it can<br>
be very challenging to implement. That's the main concern I have about<br>
cmake.<br>
<br>
Dusan<br>
<br>
______________________________<wbr>_________________<br>
Ncep.list.fv3-announce mailing list<br>
<a href="mailto:Ncep.list.fv3-announce@lstsrv.ncep.noaa.gov">Ncep.list.fv3-announce@lstsrv.<wbr>ncep.noaa.gov</a><br>
<a href="https://www.lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.fv3-announce" rel="noreferrer" target="_blank">https://www.lstsrv.ncep.noaa.<wbr>gov/mailman/listinfo/ncep.<wbr>list.fv3-announce</a><br>
</blockquote></div><br></div>