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

CI - build multiple targets #95

Closed
CDKnightNASA opened this issue Jun 2, 2020 · 4 comments
Closed

CI - build multiple targets #95

CDKnightNASA opened this issue Jun 2, 2020 · 4 comments

Comments

@CDKnightNASA
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The build process becomes increasingly more complex when building for multiple targets. CI should build for at least two targets to ensure that the build system is functioning properly.

Describe the solution you'd like
Have CI create relevant build configuration to build for multiple targets.

Requester Info
[email protected]

@JandlynBentley-at-NASA JandlynBentley-at-NASA removed their assignment Jun 24, 2020
@skliper skliper added CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) and removed good first issue Good for newcomers labels Jul 27, 2020
@skliper
Copy link
Contributor

skliper commented Jul 27, 2020

In light of the conversation in nasa/cFE#758, this needs more discussion as to how it should be implemented.

Some options

  • Make it a built in option as part of sample_defs, CI just sets a flag
  • poke in changes, or patch
  • add separate *_defs for CI with "special" configurations

@skliper skliper closed this as completed Jul 27, 2020
@skliper skliper reopened this Jul 27, 2020
@CDKnightNASA
Copy link
Contributor Author

In light of the conversation in nasa/cFE#758, this needs more discussion as to how it should be implemented.

Some options

  • Make it a built in option as part of sample_defs, CI just sets a flag
  • poke in changes, or patch
  • add separate *_defs for CI with "special" configurations

Not sure if this is one of the options you describe above, but my original thought was that .travis.yml would have a simple sed script that would uncomment the CPU2 entries in targets.cmake prior to build/test/etc. Probably the most minimal impact.

@jphickey
Copy link
Contributor

Note the changes in nasa/cFE#776 to use name-based (rather than number-based) target definitions make this substantially easier to implement. Shouldn't be a need for sed scripts to hack the targets.cmake file if we go this route for future CFE versions.

@astrogeco astrogeco added CCB-20200902 and removed CCB:Ready Pull request is ready for discussion at the Configuration Control Board (CCB) labels Sep 2, 2020
@astrogeco
Copy link
Contributor

CCB 2020-09-02 Keep open, see implementation in SBN for inspiration.

chillfig pushed a commit to chillfig/cFS that referenced this issue Mar 17, 2022
This bit indicates that the PDU has 64-bit size and offset fields.
CF currently does not support large file sizes.  It needs to reject
these packets as they will corrupt the data because they are not
decoded properly (decode is fixed at 32 bit sizes).
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

5 participants