Adding cFS apps to startup script and targets.cmake

[RR-HSz]

It would be easier to integrate applications if they were added by default to the strartup script and targets.cmake as a commented line. This way the integrator should only uncomment the line(s) referring to the application.

[skliper]

As alternative to commented lines (that often go stale) consider adding a target (to sample_defs) that has all the open source apps that are supported by the core team, and a startup script for that target. Would be a good example for how multiple targets work and how easy it is to have a target specific startup script as well as support CI of all the open source apps from the cFS bundle.

[ivanperez-keera]

I propose to evaluate transitioning to a directory-based setup, where the presence of a file/link in a directory is what enables an app, similar to how one can add files into /etc/apt/sources.list.d/ instead of adding lines to the file /etc/apt/sources.list. That way, bringing applications into an existing installation would be easier, and the files in cFS would not have to be modified (so one could potentially also do a git pull on a cFS installation and update cFS without conflicts.

[skliper]

I propose to evaluate transitioning to a directory-based setup...

Interesting idea and could probably be just a couple lines in the sample targets.cmake to add a target with everything in apps/libs. Maybe an additional capability to autogenerate a default companion startup script (based off of recommended settings supplied by each element)? Need to retain support for selecting a subset since I think it's a common use case to have multiple targets that don't include everything. For example we have multiple sim targets and a flight target that select different apps/libs.

Although in the end it seems like it'd be very easy for the autogeneration of a startup script to get it wrong (how would apps know what priority to assign?), so I'm not sure it's worth the effort or added complexity. Could end up just being more confusing if the inputs get distributed vs just maintaining the script by hand.

[RR-HSz]

There is a similar approach with the HAVE_* macros, where sch_lab and to_lab tries to determine if a given list of applications are available (see CMakeLists.txt in SCH_LAB and TO_LAB applications).

[ivanperez-keera]

IMO the current "scripts" try to be too smart. They try to discover things automatically (for example, with the _defs autodiscovery). It might be good to be able to pass parameters to the compilation.