os: Adds RTOS constraint_values

[silvergasp]

Adds Embos, FreeRTOS and ThreadX as constraint_values for constraint_setting 'os'.

Example use case: Select backends for pwsync* based on the OS for Pigweed.

[silvergasp]

cc @Keir @akirabaruah

[aiuto]

Can you tell me more about the need for this? We are short on guidelines for new additions, so, in lieu of those, let me summarize my concerns.

• We want to only add things of universally recognized value. Anything here is a constant that should be used by any Bazel project. So we would like to have (but don't have yet) a bar for 'yes, everyone users this word to mean this OS'
• We want to avoid adding everything in the world, because that will inevitably result in us playing referee to competing niche projects that want to carve out the namespace
• Instead, we would like to provide a best practice for how each organization can import this repository and augment it with the set of names they might require locally for their products.

Can you hold out until that example of import is developed?

[silvergasp]

Can you tell me more about the need for this?

Here is an example of where we are using it. In short Pigweed has a set of facades, and for each facade a set of backends that need to be selected based on differing CPU and OS constraints.

NOTE: The CL is on hold until we work out if this is going to be a good fit with this repository. Otherwise we will have to find a workaround.

We want to only add things of universally recognized value. Anything here is a constant that should be used by any Bazel project. So we would like to have (but don't have yet) a bar for 'yes, everyone users this word to mean this OS'

I think that for the most part these are universally recognised values.

We want to avoid adding everything in the world, because that will inevitably result in us playing referee to competing niche projects that want to carve out the namespace

Understood that is very much a valid point. I guess the ideal 'bar' to compare against is to ensure that each constraint_value is irreducibly and explicitly X os. To be fair to you on that front, this PR wouldn't necessarily meet that criteria. e.g. In the case of FreeRTOS there are a variety of backends for different target platforms. In the case of FreeRTOS (and other RTOS's) it's not uncommon for the backend to be built on another RTOS. There is definitely some subtleties in the embedded world and even an explosion of configuration options that you wouldn't necessarily deal with on a 'standard' OS. It really depends on how strict you want to be when setting the bar for new additions to this repo.

Instead, we would like to provide a best practice for how each organization can import this repository and augment it with the set of names they might require locally for their products.

I'm happy with that approach. As a side note I have a repo that I was kicking around with the Pigweed guys, that is targeted towards augmenting the existing system of constraints. Specifically that repo was intended to address #23. I don't think it solves every problem, but you might find the approach useful.

Can you hold out until that example of import is developed?

Yeah no worries, I'm not directly blocked by this at the moment, though it would be nice to have.

[silvergasp]

I think Keir touched base with you earlier. Based on a discussion about this earlier this morning I'm happy to close this PR.