The BSP 'enabled set' How do I look at it, how do I change it?

Hi everyone, again with the BSP work. So I’ve been reading through the Software Engineering documentation and it has this great topic on build items here If you look at the example the value changes based on different BSPs being built.

So far, great. So in my BSP I want to have a BSP option that lets me select the ‘flavor’ of this BSP (flavor here being a slight variation for generally the same BSP like where the console is, as an example) So I thought I would have a option in optflavor.yml that could be set by the user or by the BSP being build so lets say it set ICECREAM_BSP_FLAVOR to one of vanilla, chocolate, or strawberry. If I dump the BSP options using WAF it shows I’ve selected strawberry. Now I want an option that changes based on what the ICECREAM_BSP_FLAVOR option is set to, so I have an opttastes.yml that does something like:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause                                                              
actions:                                                                                                           
- get-string: null                                                                                                
- define: null                                                                                                     
build-type: option                                                                                                 
copyrights:                                                                                                        
- Copyright (C) 2026 me
define:
- enabled-by: vanilla
   value: "bland"
 - enabled-by: chocolate
   value: "tasty"
 - enabled-by: strawberry
   value: "fabulous"
 - enabled-by: true
  value: "not specified"
format: '{}'
name: ICE_CREAM_TASTE_OPINION

But no matter what I set the flavor to the only thing it ever sets it to is not specified (the default true value) rather than an actual value.

I verified (by putting another - enabled-by: true item at the top that as the manual suggests the first one to evaluate to true is used. While I might have YAML syntax errors in my example here I have a syntax checker that I use with these files and the actual code is fine.

The RTEMS Software Engineering manuals say “if the value is in the enable set (emphasis in the manual) then it returns true” But it never actually defines what the ‘enable set’ is other than saying “Its the things that are enabled” and how I might add to it in my YAML option files.

–Chuck

Okay, one suggestion (and a great pointer) was to the docs which describe the actions for your option. Suggesting the env-enable was the one I was looking for. I’ve tried putting the env-enable in the flavor option YAML. That doesn’t seem to make it visible to the taste opinion YAML that looks for the flavor specified.

And it doesn’t seem to be case sensitive, in that STRAWBERRY and strawberry both don’t work

A further update.
I don’t think I can do what I want to do here. WAF can’t handle it. What I would like to do is use a YAML file to build a mapping that would allow the contents of a build define to be based on my_mapping[key] but tracking through the WAF code it seems the variables you can select on are set before YAML parsing begins so you cannot add variables with YAML files that are available to later YAML files to make decisions with. You do get the name of the BSP you’re building so when you’re sharing a YAML file across several BSPs you can have it change its behavior based on the BSP you’re building. But you cannot effectively build a late binding BSP.

I would have expected that a default beneath the define instead of enabled-by: true would work.

Yeah, I tried a lot of different things. But alas. There are three “timelines” in play hear, the first is WAF constructing the environment, the second is WAF using the environment to build the thing. (the third is installing the thing). WAF’s first phase is controlled entirely by ‘enable/not-enable’ state (kind of like ladder logic) and has no self reflection, so it doesn’t have a way to express an enable statement consisting of what is in the currently constructed environment, only statements that operate on what the environment was when it was started. As a result you get some workarounds.

There may be a way to hack it with script options since they can run arbitrary python code.