[PATCH] spec/libdebugger: Only enable for supported architectures

[Chris Johns]

On 22/10/21 1:21 am, Sebastian Huber wrote:
> On 21/10/2021 10:36, Chris Johns wrote:
>> Could you please answer the other parts of the email you cut because it would
>> help understand this stuff?
>>
>> Specifically the opt* and user options. When is an option optional and when is
>> an option an option but not optional?
> 
> The option item files are used for both user options and internal options.
> 

OK I think this now makes sense. An option can be a user controlled with a
default or a variant dependent on the build characteristics, for example
architecture?

>> On 21/10/21 7:09 pm, Sebastian Huber wrote:
>>> On 21/10/2021 10:06, Chris Johns wrote:
>>>> KeyError: '/cpukit/optlibddebugger'
>>>>
>>>> You have to admit this is a horrible error message. It provides no insight into
>>>> problem or the solution.
>>>
>>> Looks like a typo. Maybe use optlibdebugger?
>>
>> Yes it was. Thanks. However I am still confused.
>>
>> If I add optlibdebugger to cpuopts.yml which is:
>>
>>   build-type: config-header
>>
>> I would expect libdl and libdebugger to appear in cpuopts.h as enable variables
>> but they do not?
> 
> What the option items to is defined by the actions attribute, for example
> (spec/build/cpukit/optlibdl.yml):
> 
> actions:
> - set-value: true
> - env-enable: null
> 
> This adds the option name to the enabled set.

Thanks. And `name` is the name field?

>> Why are they in this YAML file?
> 
> This is to order the build properly.

OK. Is it fair to say cpuopts is a convenient way to centralise this?

>>
>> The the libdebugger YAML file I need:
>>
>>   enabled-by: BUILD_LIBDEBUGGER
>>
>> or:
>>
>>   enabled-by:
>>    - arm
>>    - i386
> 
> If the option file adding BUILD_LIBDEBUGGER to the enabled set is processed
> before the libdebugger.yml and it uses the same enabled-by expression, then you
> can use both.

Both of what?

How would I add a define to the actual cpuopts.h file?

I wonder if adding libdl and libdebugger would be useful given they are not
universally supported?

>> however `enabled-by` is not in:
>>
>> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuildlibraryitemtype
>>
>>
>> Is it OK to do this?
> 
> Yes, just follow the "refines" link to the root type.
> 
>>
>> It is great this is working but it is confusing understanding why and that means
>> it is hard to know what you can do and not do?
> 
> The items have a fixed set of top-level attributes which are all documented.
> What you should definitely not do is adding new attributes to existing files.
> This is an absolute no go.

Would it make sense to capture the constraints of each `build-type`? It would
have helped me here if an error was generated when I added `name` to the
`build-type` library. I can see `constraints.yml` as a top level file that is
read in and to used to monitor what is present in each built-type.

> We should gradually improve the documentation. Maybe the enabled-by attribute
> needs more explanations.

Agreed. And the options and what they are used for? I considered their use was
literal and user facing.

Chris