How to best structure a multi-deployment project.

[ReggieMarr]

Hi all, I'm currently re-structuring the repo's I work on for developing flight software with F'.

The goal here is to support a base project structure which can be shared publicly but breaking out Deployments and Components such that some can be isolated as submodules.

I.e. something like this:

project root
    - Deployments
        - PublicDeploymentA
        - PublicDeploymentB
        - private (submodule)
    - Components
        - PublicComponentA
        - private (submodule)
     deps
         fprime

Now managing references isn't too big of a deal since I can just set the project root in cmake to the root of the base repo however this gets a bit more complicated when it comes to deployments.

It appears fprime-util really wants the project structure to look something like this:

project root
    - CMakeLists.txt
    Deployment
        CMakeLists.txt
     fprime

Where the root CMakeLists.txt has knowledge of all Deployments and Components.

I've managed to make some progress with work arounds but I end up with Deployment targets like "Deployments_target_Deployment" and that's a bit annoying.

Is there perhaps a better approach than what I'm taking ?

[zimri-leisher]

This was quite difficult for us too. We eventually got it working, but we had to do some strange hacks involving autocoding the settings.ini file and aliasing target names in CMake. It feels like the CMake system is not designed with this in mind. Would be curious to know if we're missing some CMake feature that could make this easier.

[ReggieMarr]

I'm curious what drove you to autocode the settings.ini did this allow you to better break up components that are used across different deployments ?

I think there's a real issue where some parameters can be defined/set either when executing fprime-util, in the settings.ini, in the CMakePresets.json, or in the CMakeLists.txt and it's not clear what the best practices are.

[zimri-leisher]

We needed to build all UTs in a submodule (but nothing else). At the same time, we needed to build deployments which were outside of the submodule. We could not figure out how to get this working with the current settings ini