VERY IMPORTANT: ROMS compiling with MAKE Revisited

[arango]

We are modernizing the compiling of ROMS with gmake. The strategy has been since the beginning to create a static library for each sub-directory of ROMS source code. However, it is inconvenient nowadays because the compiling needs to be done in a specific order. Also, it is less efficient.

Therefore, the makefile, build scripts, Module.mk, and compiling and computer-specific configuration files (Compilers/*.mk) are modified to create a single STATIC and or SHARED library:

 libROMS.a            (static library)
 libROMS.so           (shared library)
 libROMS.dylib        (macOS shared/dynamic library)

It is similar to the strategy of compiling ROMS with CMake. It facilitates ROMS coupling with third-party systems like CMEPS/CDEPS and the integration to modern data assimilation systems like JEDI. A single ROMS library (libROMS) is passed to such systems.

Building a ROMS shared library is recommended for advanced users and specific applications that require it:

• Notice that you cannot delete or rename the standard Build_roms or Build_romsG directory containing the C-preprocessed, objects, modules, and library files because they are required to keep track of the objects in the shared libROMS.{so|dylib}. Those object will be lost and replaced with a new build.
• Static linking generates larger executables than shared/dynamic linking because it must compile all the code directly into the ROMS executable.
• Shared/dynamic libraries are smaller and place the calls at runtime to shared code objects. As a result, it has faster load times. In addition, it reduces disk space, memory, and improves multitasking.

Therefore, there is a tradeoff between static and shared libraries that require expertise. By default, we recommend using static libraries.

The build_roms.csh and build_roms.sh are modified to include options to create static and or shared ROMS library(ies). For example, in build_roms.sh, we have:

#export            SHARED=on            # build libROMS.{so|dylib}
 export            STATIC=on            # build libROMS.a

WARNING: If both SHARED and STATIC are turned on, in most computer operating systems (except CYGWIN), the shared library will be used to generate the ROMS executable.

Also, there is an option to create a specific ROMS executable:

export              EXEC=on            # build roms{G|M|O|S} executable

One could only run the build script to produce the library and not the executable (romsG, romsM, romsO, or romsS).

Still, ROMS can be compiled with the old build scripts. In such a case, ROMS will generate and be compiled with the static library (libROMS.a).

WARNING: Unfortunately, for the new static and shared libraries to work correctly few changes are required to the compiling configuration (*.mk) files in the Compilers sub-directory. They are usually user-customizable, so you need to update your compiling configuration. Alternatively, you could use the CMake build scripts (cbuild_roms.csh or cbuild_roms.sh) which do not require those tedius operating system dependent compilation files (See ​src:ticket:875 and ​src:ticket:876).

Many thanks to David Robertson for implementing and testing this update.

[arango]

I corrected makefile in the git repositories. Changes were applied only to the svn repositories. The makefile in the git repositories requires different changes that I forgot.

Changed derived-type structure to pointer in yaml_parser.F:

    TYPE, PUBLIC :: yaml_Svec                      ! string structure
      character (len=:), allocatable :: value      ! scalar value
      TYPE (yaml_Svec),  pointer :: vector(:)      ! recursive vector
    END TYPE yaml_Svec                             ! values

Some compilers versions get errors if allocatable is used in the declaration.