[PATCH 1/3] build: Format build items

[Chris Johns]

On 17/1/2023 6:39 pm, Sebastian Huber wrote:
> On 17.01.23 03:48, Chris Johns wrote:
>> On 16/1/2023 6:56 pm, Sebastian Huber wrote:
>>> On 16.01.23 01:35, Chris Johns wrote:
>>>> On 13/1/2023 1:54 am, Sebastian Huber wrote:
>>>>> On 12.01.23 15:44, Kinsey Moore wrote:
>>>>>> The other two patches look fine to me. The use of dump() that results in this
>>>>>> patch does several things:
>>>>>> * Removal of whitespace
>>>>>> This is fine for whitespace at the base level of indentation. Whitespace
>>>>>> within an indented block may be more important for readability.
>>>>>>
>>>>>> * Removal of comments
>>>>>> This is not good as they are exclusively used to annotate manually ordered
>>>>>> blocks of test result expectations
>>>>>>
>>>>>> * Rearrangement of items in alphabetical order
>>>>>> In general, rearrangement of top-level sections is good. For indented
>>>>>> sections
>>>>>> specifically in tst*.yml, this is bad for the above reaso
>>>>> One goal of the new build system was to be able to alter the data through
>>>>> scripts. This requires that the build items are human and machine readable and
>>>>> writable. The Python YAML import/export does not preserve white space and
>>>>> comments.
>>>> Can someone edit the file and add a hex number?
>>>
>>> Yes, you can manually use whatever format is understood by the YAML loader. When
>>> you write the file with the YAML dumper, then the standard representation is
>>> used.
>>
>> Are there python modules in rtems.git someone could import that reads and writes
>> the YAML spec files? If not should we provide a module to do this? It could be
>> `spec` so a user can use `import spec` after setting the import path.
>>
>> That is, if external scripts (and I encourage this) all used a common read and
>> write type functionality the format consistency is relative to specific version
>> of rtems.git being used. Updates become read then write.
> 
> The Python modules to work with specification items are in rtems-central.git.
> This repository contains also a format specification of the build items.

And how does that help here with this repo? I suggest you reconsider the
accessibility of those modules before pushing scripted generation changes like
this into rtems.git.

> We
> could add an action to a Github work flow to check the build item format for
> pull requests and commits.

Thanks for including github in this thread. It has now confirmed my position of
no github automations in our repos (including rtems-central).

>>> I changed the representer to use the format attribute, see v2 of the patch:
>>>
>>> https://lists.rtems.org/pipermail/devel/2023-January/074094.html
>>>
>>
>> I see and thanks. How many format strings would cover the majority of formats we
>> have?
>>
>> I am wondering if `format:` is checked against a standard list and those are
>> part of the "writer" support? For example `address`, `address32`, `hex64` etc? I
>> am concerned about repeated common format strings being placed through all the
>> spec files.
> 
> The format string is a standard Python format string. This is easy to implement
> and flexible. We could replace this with a fixed set of formats.

Maybe if you have scripting support which this repo does not. I think the
formats should be controlled however I see the whole discussion and patch as
academic until rtems.git has scripting support in python modules.

Chris