[PATCH] spec/libdebugger: Only enable for supported architectures
Chris Johns
chrisj at rtems.org
Thu Oct 21 23:20:10 UTC 2021
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
More information about the devel
mailing list