Change build specification files from YAML to JSON?

[Sebastian Huber]

On 26.04.23 01:52, Chris Johns wrote:
> 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 don't think building an RTEMS BSP is complicated once you have the 
tools installed.

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

 From my experience with waf I would not say that the waf build system 
is simple and transparent. Things which are very easy with make are 
complicated with waf at least for me. I asked a couple of waf questions 
on the RTEMS mailing list which no core developer could answer. The 
support from the waf developer was a great help, but without this help I 
would not have been able to write the waf based build system for RTEMS.

I think our biggest obstacle to improve things in the area you outlined 
above is the scattered project infrastructure with several Git 
repositories and the lack of CI pipelines. I will probably start a 
discussion about this topic because I think our current project setting 
has severe maintenance issues.

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