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