Change build specification files from YAML to JSON?

[Sebastian Huber]

On 27.04.23 00:47, Joel Sherrill wrote:
> 
> On Wed, Apr 26, 2023 at 3:58 PM Gedare Bloom <gedare at rtems.org 
> <mailto:gedare at rtems.org>> wrote:
> 
>     Is the result of this discussion to use CSafeLoader for now? Or do we
>     still debate the transition to JSON?
> 
>     I see some quirks need to be dealt with as you mentioned with the
>     multi-line stuff. The yaml is pretty simple to understand and work
>     with. I've dealt with hand-editing JSON and it's a pain with the
>     quotes and brackets/braces.
> 
>     Since the transition is (apparently) an implementation detail, I don't
>     actually see that it matters do it now or do it after releasing 6. If
>     it doesn't change the user experience other than build time, then it
>     should matter when we do it. In that case, better to be conservative
>     to avoid rushing to push something this major so close to a release.
> 
> 
> I'm going to pile on and cynically say at this point in time, we should be
> focusing on the 6 release and not imagining new sources of churn. I am
> avoiding any opinion that would lead to change at this point in time.

I already abandoned the file format change.

> 
> I will say that with the current waf, I think I understand in principle 
> at least
> some of the high level goals for the user an I am not positive me meet these
> as well as possible even if the implementation approach could be improved.
> And nothing being discussed would improve what I see.
> 
> + look at the bsp defaults to see what configuration options are available
>     for a specific BSP family.
> 
> + write a config.ini that they put under THEIR configuration control
> 
> + possibly "create" a local BSP family variant with that INI file.
>     Assuming the configuration points exist in the BSP family.
> 
> + If their variant reflects a generally available board, then add it to
>     the BSP family as a variant.
> 
> I tried to explain the first three this week in the class and it isn't easy.
> A few observations that have nothing to do with YAML/JSON or even
> carving the settings into stone tablets.

It depends on the BSP if this is possible. The more BSP options you 
have, the easier is it to make a custom variant through the INI file.

> 
> + There was discussion that documentation of the BSP options could
> be generated from waf/specs. The comments I have seen are not enough
> to do anything useful. The BSP specific ones are usually short and cryptic.
> This is especially true when the setting is a specific hex value for an CPU
> or SoC specific register. One could guess RAM size, base address, or UART
> N present type settings.

Yes, but this is not an issue of the build system per se. The BSP 
developers are just too lazy to properly document the options.

> 
> + The philosophical goals behind the bsp defaults, a user writing an INI 
> file,
> the flexibility, etc.are not being communicated. Why do this? What's good
> about it? Why do users care? >
> + If there is discussion of using the configuration INI file to do a custom
> BSP variant, I didn't find it while looking for the class.
> 
> The last two could be me not finding something.


We have this:

https://docs.rtems.org/branches/master/user/bld/index.html#configuration

Customizing BSPs is not covered as far as I remember.

> 
> But ultimately we need to cut the 6 release branch. I think we have been
> talking about it over a year now. Let's focus and kill it.

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