Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a mechanism to push app configurations to the mission definitions folder. #48

Open
BaldBeacon opened this issue Feb 24, 2020 · 0 comments

Comments

@BaldBeacon
Copy link

After working with some of the pre-made utility apps provided by the CFE, I've noticed that at some point (relatively early) developers must abandon reuse in favor of clone/own which, in my opinion, is partly due to the CFS CMake build system not providing a clean method to push build configurations into the top level definitions folder.

An example of an app that could benefit from additional configuration would be the CI and TO lab apps. The current implementation of these apps use a hard coded port value for UDP communication with only a means to change the IP listened to via a command in TO Lab. My solution would most likely take the form of changing...

  #define cfgCI_PORT 1234

to...

  #ifndef cfgCI_PORT
    #define cfgCI_PORT 1234  // Default UDP port
  #endif

and having a config.cmake located within the missions definitions directory that contains the definition from a cmake instruction...

add_definitions(-DcfgCI_PORT=4321)

It would be nice for the CMake build system to provide the ability to have a companion configuration folder for each app in the definitions folder. This folder could contain headers and additional .cmake files used to specify certain details about the app being built.

It's currently possible to hijack the behavior of the targets.cmake file and add additional instructions like file(copy ...) to inject files into the app before it attempts to build but this would clobber the files currently present in the app directory.

chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
Correct the pipe ID assignment in UT to use the resourceID type.

This also uses a fixed/consistent value here, rather than a random
value.  There is no real need to use a random value.
chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants