Configuration

[msuder]

Transition nos3 Repository to be an Integration Only Repository Full of Submodules (and a few Integration Files)?

Integration includes submodules for:

1. fsw (cFE/cFS)
2. gsw (currently AIT/COSMOS/OIPP... maybe each should be its own repository)
3. sims (common functionality + time driver + sim terminal + truth_42_sim (maybe this should be its own repository, maybe a component?))
4. components/ - A directory containing 1 or more submodules conforming to the NOS3 component repository structure (README/fsw/gsw/sim)

What else should be in the nos3 repo?

1. Top level build time configuration
   1. Prefer CMake/CMakeLists.txt/etc. to the current Makefile (currently everything is CMake compatible except maybe some of fsw)
   2. Figure out how to specify
      1. The base fsw/gsw/sims to build +
      2. How to get to the submodule build configuration: All the components//fsw, components//sim, components/*/gsw to build
2. Top level run time configuration - Figure out how to specify
   1. The base fsw/nos3_defs/*.scr?, sims/cfg/nos3-simulator.xml files that provide an integrated top level system configuration
   2. How to get to the submodule configuration: All the components//sim/cfg, components//gsw files that provide the component configuration that need included into things like nos3-simulator.xml and 42 InOut/* and gsw/cosmos/config/system/nos3_system.txt and gsw/cosmos/config/tools/cmd_tlm_server/cmd_tlm_server.txt files that provide component configuration within the top level system configuration
3. Top level run/stop (and build/clean?) scripts
   1. What do we do with things in gsw/scripts?
4. What do we do with fsw/nos3_defs? Could fsw be a stable "distribution" of cFS for NOS3 with that removed?

Pull request quote: "For now, this is ok. We need to have a larger, architectural discussion on separating/combining configuration information in the nos3, cosmos, and individual component repositories and figure out an evolutionary improvement strategy. (Code "smell" hint... avoid ../... out of the current git repository if at all possible.)"

config/system/nos3-system.txt is one example that drove this issue:
nasa-itc/gsw-cosmos#6
https://github.com/nasa-itc/gsw-cosmos/pull/6/files/f0f0e12f3f7ab589ca91e70c579a589b6772d088#diff-ff0853b0a827937d3e41ddbc65bbd9190cb001f012b0da914d8e5a65394b70c0

Every single file change (not submodule) changed by this: #130
PR provides a place to think about whether the "information"** that "fuses" the submodules together to become NOS3 could be managed and generated in a better way (perhaps by introspection into the submodules, using CMake effectively for building, and using other tools to combine run time configuration information?).

The simulator XML configuration is especially egregious as it is the one type of this "information" where the submodules in the "components" directory do not have their own copy of their own information in sims/cfg (other component development pull requests will also reveal the need for viewing 42 SC_*.txt and Inp_IPC.txt files as containing overarching NOS3 configuration information and component submodule configuration information that ideally should be split out and automagically combined also).

** information: examples include build time (e.g. fsw/nos3_defs/targets.cmake and runtime (all the other modified files such as FSW .scr start script, scheduler and TO tables, launch scripts, and simulator XML configuration)

[jlucas9]

[msuder]

This was the document I created a few years ago when I was thinking about what should be submodules, what should be top level, what a build could look like, etc.
SSPOMissionRepoBuildDeploy.docx

[jlucas9]

Merged to dev