Refactor directory structure so it makes sense again (fsw contains non-fsw)

[skliper]

Is your feature request related to a problem? Please describe.
fsw is misleading in that it includes unit tests, etc but then there are also fsw implementations within modules...

Describe the solution you'd like
Implement a flattened/sensible directory structure. Needs discussion.

Describe alternatives you've considered

• cfe/
  • CMakeLists.txt for the repo
  • fsw/
    • CMakeLists.txt for the fsw
    • sbr/
      • CMakeLists.txt for sbr (and so on for CMake files)
    • msg/
    • core/
      • es/
      • ...
    • public_inc/
  • unit-test/
    • stubs/
    • coverage/
    • functional/
  • eds/
  • docs/
  • ... and so on

Additional context
#947 (review)

Requester Info
Jacob Hageman - NASA/GSFC

ping @acudmore

EDIT - updated for Gerardo comment

[skliper]

Also related to #626 (utilize cmake libraries) that could help clean up includes/dependencies.

[astrogeco]

I would also suggest a unit-test directory with functional, stubs, and coverage subdirectories

[astrogeco]

CCB 2020-10-28 APPROVED

Something like the simplified tree in the original comment would be great.

[astrogeco]

I assume "core" contains the base services (es, evs, etc.). What do we get from nesting those as opposed to keeping them directly under "fsw"

[skliper]

I assume "core" contains the base services (es, evs, etc.). What do we get from nesting those as opposed to keeping them directly under "fsw"

The "core" services all use one CMakeList.txt, and become one cfe-core library in the build context. The individual modules each have their own CMakeLists.txt and can be removed/replaced via configuration. Eventually everything could follow the module approach and we could break out cfe-core into it's elements, but we aren't there yet (and it's not critical for Caelum).

[jphickey]

Need to consider how this affects the build system and the way it finds components. In particular the component-level CMakeLists.txt files need to reside at the top level of the module they define.

I have two possible suggestions for consideration. The first is a "lighter" version that still preserves the current core grouping and wouldn't substantially impact the general build scripts or user understanding of the layout:

.
├── cmake
│   ├── sample_defs
│   └── target
│       ├── CMakeLists.txt
│       ├── inc
│       └── src
├── core
│   ├── CMakeLists.txt
│   ├── eds
│   ├── fsw
│   │   ├── es
│   │   ├── evs
│   │   ├── fs
│   │   ├── sb
│   │   ├── tbl
│   │   └── time
│   ├── mission_inc
│   ├── private_inc
│   └── unit-test
│       ├── coverage
│       ├── functional
│       └── stubs
├── docs
└── modules
    ├── cfe_assert
    │   ├── CMakeLists.txt
    │   ├── inc
    │   └── src
    ├── cfe_testcase
    │   ├── CMakeLists.txt
    │   └── src
    ├── cfe_testrunner
    │   ├── CMakeLists.txt
    │   ├── inc
    │   └── src
    └── msg
        ├── CMakeLists.txt
        ├── mission_inc
        ├── src
        └── unit-test
            ├── coverage
            ├── functional
            └── stubs

In this approach the MISSION_CORE_MODULES would be modified to contain core instead of cfe-core but it should otherwise work as long as the corresponding search path is updated, I don't think it would require much script modification other than to adjust the paths.

The second is a more full-blown modularization, which is what I think we should strive toward but is definitely a bigger change not only in the scripting but also user mindset:

.
├── cmake
│   ├── sample_defs
│   └── target
│       ├── inc
│       └── src
├── docs
└── modules
    ├── cfe_assert
    │   ├── CMakeLists.txt
    │   ├── inc
    │   └── src
    ├── cfe_testcase
    │   ├── CMakeLists.txt
    │   └── src
    ├── cfe_testrunner
    │   ├── CMakeLists.txt
    │   ├── inc
    │   └── src
    ├── es
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    ├── evs
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    ├── fs
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    ├── msg
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    ├── sb
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    ├── tbl
    │   ├── CMakeLists.txt
    │   ├── eds
    │   ├── fsw
    │   │   ├── inc
    │   │   └── src
    │   └── unit-test
    │       ├── coverage
    │       ├── functional
    │       └── stubs
    └── time
        ├── CMakeLists.txt
        ├── eds
        ├── fsw
        │   ├── inc
        │   └── src
        └── unit-test
            ├── coverage
            ├── functional
            └── stubs

In this approach the MISSION_CORE_MODULES would list out all individual core modules directly, i.e. instead of cfe-core it would have es evs sb tbl time fs and we would have to do some work to deal with the current places that core apps call internal functions or reference internal data structures in other core apps - either promote them to public or come up with a different way to handle it. (this is the current fsw/cfe-core/src/inc/private dir - which I'd like to see go away).

Correction - removed core/inc from second - all include files would be in respective modules in the full-modular approach.

[astrogeco]

Uh-oh we're approaching taxonomy territory!

[skliper]

I'd prefer an approach that separates fsw from non-fsw. Your modules directory mixes that concept in both options (as does the current structure). I think we would benefit from an obvious difference.

[jphickey]

Yes - The reality is that all modules may have both fsw and non-fsw components. This is true of all apps and libraries. Ideally - in a general sense - when a user adds modules (of any kind) to their build, they want to add the FSW stuff as all supporting stuff - tests, documentation, etc as one logical unit.

I don't see why we'd want to treat the core modules any differently - they are just other modules.

So the very general form/template would be:

• CMakeLists.txt at top level for overall app build recipe (builds FSW plus any supporting stuff)
• eds dir for CMD/TLM definitions
• fsw dir for actual code that is executing on the flight processor - divided into inc for public API and src for source files
• unit-test dir for the tests (could be simplified to just test)
• docs dir for documentation (not shown earlier, but we should probably have it!)

Edit: Clarified to add "may" into first sentence.