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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
