[PATCH 1/3] build: Format build items

[Sebastian Huber]

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. We could add an action to a Github work flow to 
check the build item format for pull requests and commits.

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

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/