Change build specification files from YAML to JSON?

[Chris Johns]

On 25/4/2023 5:35 pm, Sebastian Huber wrote:
> Tooling makes sense if you have a high change rate. 

That is not the use case I am discussing and it is not a factor.

> This is not the case for the RTEMS build specification items.

I am not saying it is.

> For which use case do we need tooling support?

We need tooling to lets us all understand this build system. YAML is easy to
learn however the data-structures, rules and the large number of file fragments
we have are complex and not apparent to anyone looking at it even if you have
invested time doing so. It reflects the fact that RTEMS is complicated to build.

I am advocate for what we have and will continue to be one so I am attempting to
address some things we could do better. History has shown the RTEMS core
developers are not great judges of the community's view of the project's
usability and accessibility.

The analogy is to consider the git command then the roles github and gitlab
provide with their user interfaces and tooling.

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

My experience tells me it is not as simple as this. There is an element of guess
work a change is right. The recent dependency cases highlighted this and the
need for checking of some form to be present in the rtems.git repo.

We need to step back and consider the role of the build system before we discuss
implementation details.

The first requirement by a large margin is ease of use for users and the
community to make contributions. Meeting this requirement can be done a number
of ways. For example a user focused format for the relationships rather than one
that aids machine integration. The original ground work Amar did for the move to
waf was to define the build in Python as documented by waf. It was simple and
transparent. Another example is a machine focused format however we need tooling
to help the users manage making changes and accessing what is happening without
needing to learn the details of how it is implemented.

For tooling my order of importance is:

1. Visualise the structures and dependencies in a human readable manner. An
indication of which file is doing what would be helpful.

2. A check of changes users make that raises errors, dependency problems, etc.
This can be a command you run if you are making changes and does not need to run
every build.

I see JSON and tooling as linked together. I also not expect complete tooling to
be present for the change to happen. All I am wanting is the need for tooling be
agreed on and it is located in rtems.git. The development can then happen and
evolve as the community sees a need.

Chris