Change build specification files from YAML to JSON?

[Sebastian Huber]

On 24.04.23 23:45, Chris Johns wrote:
> On 25/4/2023 12:20 am, Sebastian Huber wrote:
>> On 24.04.23 16:17, Kinsey Moore wrote:
>>> I think we've been moving away from in-file comments in the YAML and toward
>>> actual labels in the data, anyway. If it's important information, it should be
>>> kept properly.
>>
>> Yes, there should be no comments in the build specification files. They would be
>> lost in YAML load/save cycle.
> 
> I am fine with json as a format. Comments are useful even for copyright notices
> which would be lost. Is that OK?

We don't have comments in the build specification files. There is an 
attribute for copyright notices, for example:

SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: library
cflags:
- ${COVERAGE_COMPILER_FLAGS}
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
cppflags: []

> 
> My concern is a major shift on top of a major change to waf so close together.
> As a community we have only just started to get a number of people across what
> we have and then things change? I see the counter point about making this happen
> before 6 however I am still not sure what the cost/benefit is?

The change from YAML to JSON for the build specification files is just 
an implementation detail of the new build system. For the users of the 
new build system nothing changes. If we want to change to JSON, then 
this should definitely happen before the RTEMS 6 release or not at all. 
The cost of moving to JSON is that the file format is a bit more verbose 
(lots of " quotation). The benefit is a less complex wscript and faster 
build times. The change is trivial to do:

https://github.com/sebhub/rtems/commit/47c1e7218984ad0140d677d21c8526ec4fef653e

The JSON files produced by the Python json.dump(data2, out, 
sort_keys=True, indent=2) have a Git friendly format.

A bit problematic is multiline content:

https://github.com/sebhub/rtems/commit/47c1e7218984ad0140d677d21c8526ec4fef653e#diff-5a11531b07bc2a92e083a72414b45f96824a276a4dd925f9639cfc40081cba4b

We could work around this by using a list of lines.

> 
> The YAML lacks support tooling in rtems.git but it is usable as is. I am
> concerned a move to json would compound the problem. On the other hand if we
> considered json as the data could tooling mean we avoid hand editing?
> 
> If that was the approach how would we move to have tooling to help?

Tooling makes sense if you have a high change rate. This is not the case 
for the RTEMS build specification items. For which use case do we need 
tooling support? For a new option or BSP, you just copy and past from 
existing files/BSPs. Changing a specific part of an existing file is 
just copy and paste some lines and edit them in most cases.

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