Is your feature request related to a problem? Please describe.
The OSAL build script always looks for BSP implementations in:
${OSAL_SOURCE_DIR}/src/bsp/${OSAL_SYSTEM_BSPTYPE}
Likewise it always looks for OS implementations in:
${OSAL_SOURCE_DIR}/src/os/${OSAL_SYSTEM_OSTYPE}

This presents a challenge to for a user with a custom OS/BSP implementation not within the mainline OSAL source tree, but wishes to use the github repo directly.

Describe the solution you'd like
It should be possible to provide an external directory that the OSAL build can use.

Describe alternatives you've considered
Create an OSAL fork or "git subtree" to assemble a full CFE/CFS repo, which allows one to add custom packages or patches they need.

Additional context
The internal API between the BSP/OS implementation components is not stabilized like the public API is, and can change any time.

If directly using a "master" branch from github in conjunction with a locally-controlled implementation module, users may experience frequent breakage, as the component interface can change any time rendering it incompatible with their local version.

In contrast, although the fork/subtree approach does have a similar issue, it doesn't happen "automatically" - it requires a specific user action to pull and merge the new "master" so it creates a buffer that avoids unsolicited breakage.

This feature should come with a big disclaimer that says its for debug/development only, not to use it in production.

Requester Info
Joseph Hickey, Vantage Systems, Inc.