Fix95, CI build multiple targets

[JandlynBentley-at-NASA]

Describe the contribution
Added a CPU2 as a second target to the build configuration to ensure build system is functioning properly with Travis CI for multiple targets.

Also added the following files:

• cpu2_cfe_es_startup.scr
• cpu2_platform_cfg.h
• cpu2_msgids.h

Resolves: cFS bundle's issue 95 nasa/cFS#95

Testing performed
Steps taken to test the contribution:
Went through the build steps from "Build and Run" section of https://github.com/nasa/cFS

Expected behavior changes
Expected to see cpu2 in the exe directory, but it did not appear; still only cpu1 was made for me.
However, this worked for Chris Knight after he cloned cFS and pulled from my fork (cpu1 and cpu2 were made).

System(s) tested on

• Hardware: Mac OS
• OS: Ubuntu 18.04 via VirtualBox

Contributor Info - All information REQUIRED for consideration of pull request
Jandlyn Bentley, NASA-GSFC

[JandlynBentley-at-NASA]

In my original commits from git, it looks like it might be linking to the cFE issue #95 which is not correct. This pull request is intended to resolve nasa/cFS#95.

[skliper]

Don't change the default behavior of cFE out of the box. This should be part of CI if you want to check 2 targets with CI.

[skliper]

In my original commits from git, it looks like it might be linking to the cFE issue #95 which is not correct. This pull request is intended to resolve nasa/cFS#95.

You need to open an issue in this repository specific to the changes you are doing here. As noted above, don't change the default, out-of-the-box behavior of cFE/cFS. You can add the sample configuration files (which is what I recommend you write the issue to do), but the actual configuration change to build 2 targets should be done with CI from cFS.

[JandlynBentley-at-NASA]

I didn't see how to make adjustments in .travis.yml because it looks like CI only does one build for all targets.

[skliper]

I didn't see how to make adjustments in .travis.yml because it looks like CI only does one build for all targets.

The CI in nasa/cFE doesn't build anything. That's why the issue is in cFS, at which it does a matrix build of the entire framework. I recommend from cFS, write a script to reconfigure the system to build 2 CPUs (the part that I said don't do in this repo), and add another build to the cFS matrix that calls that script and does the two CPU build.

[skliper]

In fact it may make more sense to not add these files, since they are (I assume?) just a copy of the cpu1 files. Rather just copy them from cpu1_* as part of the script. Otherwise we'd now have 2 sets of files that we need to keep up to date. The copy is trivial and I'd think it would always work if just building.

[CDKnightNASA]

We currently have targets.cmake with (commented out) CPU2 & CPU3, either we should remove those entries and have .travis.yml create entries or we should have all of the relevant files in sample_defs to support CPU2/3 if they are uncommented and just have .travis.yml uncomment the entries. We can discuss at CCB today?

[JandlynBentley-at-NASA]

The only reference I could find regarding multiple targets in the Travis CI documentation was here: https://docs.travis-ci.com/user/build-stages/#naming-your-build-stages

It looks like we'd have to make two scripts?

[CDKnightNASA]

The only reference I could find regarding multiple targets in the Travis CI documentation was here: https://docs.travis-ci.com/user/build-stages/#naming-your-build-stages

It looks like we'd have to make two scripts?

What I suggest you do is have travis alter the targets.cmake and create the addl. .scr and .h files, then just do a single build (which will create multiple CPU's).

[jphickey]

Note you can put targets inside an "if" statement like this:

if (TEST_TARGETS GREATER 1)
   set(TGT2_NAME cpu2)
   ...
endif()

Note this isn't a pattern I'd recommend projects clone for their own mission config, but it works for CI. We can also have CI-specific "defs" directories stored in a separate CI repo. Ideally for an extended validation test we should build with other CFS apps, and old/imported configs like real projects would. This may not always work, but we should know if we broke it, as it means we probably need to add something in the release notes to guide users that are upgrading.