Use case

new code is mostly added to existing modules instead of being broken out into smaller modules. existing modules grow larger and more difficult to maintain as the years go by. it can also complicate the dependencies between modules since fortran doesn't allow circular references in modules.

Is your feature request related to a problem?

as developers add new routines to the system, 90% of the time they add them to existing modules instead of breaking out closely related functions into smaller separate modules. this is because to move routines between files requires updating 100+ path_names files in the system which is onerous, and then updating the use lines in all the source code which is doubly onerous. (there are no good tools for constructing the use lines automatically, so many files already contain use routines which aren't actually needed because they are copied from another file to start.) maybe more importantly, this also breaks functionality for any user executables where their path_names and source files aren't in the public repo so we can't update them.

Describe the your preferred solution

if i get hit by a bus, here's as far as i've thought it through.

• every module EXCEPT the locations mod, the mpi-related mods (mpi_utils, win_mod) and the model_mod should be built and archived (ar) into a library, libDART.a and/or libDART.so
• user code should: use dart_lib_mod, only: xxx, xxx, xxx
• a single dart_lib_mod can "use" all the source mods and only that one file should need to change if a new module is added or routines are moved between modules. there would be no code in this module, just a series of use lines for the entire set of public routines
• path_names files only contain the appropriate locations mod (oned, threed_sphere, etc), mpi or non-mpi mods, and the model_mod plus any additional modules needed by the model_mod.
• mkmf should make executables dependent on libDART. it might take a new option, or that functionality may already be there. the make rule for libDART could be to cd to the DART/lib directory and build the library there with a static makefile. then quickbuild and mkmf_xxx work the same as before. if libDART is up-to-date it is just linked with the program; if not it is built the first time.
• the linker flags can use " -L $DART/lib -lDART " (that's dash ell DART) and that takes care of linking in the library whether it is built static (.a) or dynamic (.so)
• OR, the library could be listed just like source files in the path_names file. that would allow different versions of the dart library to be used by changing the path_names file. i don't know if mkmf knows what to do if a file in the path_names is a library. it might work already, or we might have to add additional capability to mkmf to go build the library (cd into the library directory; make libname) if it doesn't yet exist.

Describe any alternatives you have considered

i haven't thought of another good way to package this so changes in where the source code lives is transparent. it is sorely needed. the utilities module is too large; the filter_assim module needs refactoring and some routines moved out; the obs_sequence module contains routines which don't need access to any of the internal data structures and could be moved out. (obs_sequence also has some obs_def code in it which i think could be separated if the module was broken into smaller pieces, but i'm not 100% sure about this.) since we encourage the fortran "use only ... " syntax moving routines means not only changing path_names files, which could possibly be automated, but also editing all source files which is a much trickier and painful change.