Fix #140: Add compile definitions for self-contained build

[irowebbn]

Describe the contribution
A clear and concise description of what the contribution is.

• Fixes Does not build without feature test macro set externally #140

Testing performed
Steps taken to test the contribution:

1. make distclean; make prep; make

Expected behavior changes
A clear and concise description of how this contribution will change behavior and level of impact.

• No behavior changes

Contributor Info - All information REQUIRED for consideration of pull request
Isaac Rowe, NASA JSC (Jacobs Technology)

[dzbaker]

30 November 2023: Closing as we are not targeting elf2cfetbl being runnable outside of cFE.

[irowebbn]

I don't understand this rationale. The purpose of this is not to make elf2cfetbl runnable outside of cFE, but to correctly declare dependencies. mission_build_custom.cmake is marked as an example file, but the XOPEN_SOURCE directive is required for elf2cfetbl to compile correctly. If you want all the components to have it defined for them, then I guess it could go into mission_build.cmake, but ideally each CMake target should define its own requirements.

[dzbaker]

@irowebbn XOPEN_SOURCE isn't something that elf2cfetbl needs/uses, but rather something needed by the development environment/C library. These definitions are intended to go in mission_build_custom.cmake.

[irowebbn]

I'm sorry, but I still don't understand. elf2cfetbl uses ctime_r, which is only visible when setting the XOPEN_SOURCE feature test macro.

Setting the macro in mission_custom_build.cmake is problematic for 2 reasons:

1. The *_custom_*.cmake files are meant to override default build behavior. But setting this feature test macro is necessary for the elf2cfetbl target to compile. Necessary build steps should be separated from configurable options. There's nothing indicating that some of the options in what cFE provides in sample_defs should not be changed. This was the primary reason I submitted the patch.
2. This defines the macro for all the targets for local tools. Do all the targets need to have those symbols visible in order to compile? No, each target should be able to control the visibilities for themselves. Imagine I had a target that strictly followed the C standard but had conflicts with symbols brought in by the feature test macro. Probably a bad idea, but permitted nonetheless. I would have to use target_remove_definitions to undo what the mission_custom_build.cmake brought in.