[PATCH 1/3] build: Format build items

[Chris Johns]

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.

> 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.

Chris