Change build specification files from YAML to JSON?

[Joel Sherrill]

On Wed, Apr 26, 2023 at 3:58 PM Gedare Bloom <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 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.

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

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

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.


>
> On Wed, Apr 26, 2023 at 2:30 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > On 26.04.23 00:37, Chris Johns wrote:
> > > On 26/4/2023 4:01 am, Sebastian Huber wrote:
> > >> We have a fraction of a second if we use the CSafeLoader and no item
> cache.
> > >> Currently we use the SafeLoader which results in about 5 seconds. I
> would like
> > >> to use the build system for more stuff, so this could grow to 10, 15,
> or more
> > >> seconds which then start to get annoying if you work frequently with
> it.
> > > Then please outline what all you have in mind and what the long term
> plan is
> > > then we can consider the overall direction.
> >
> > We work on a prototype to build libbsd, lwip, abseil-cpp, googletest,
> > jsoncpp, libsodium, nats.c, protobuf, protobuf-c, utf8_range, cfs,
> > zephyr, chip vendor HALs, etc. with the RTEMS build system.
> >
>
> This is interesting although it appears to be quite a bit of scope
> creep. I guess the intent is to help with traceability of these
> projects too?
>
> -Gedare
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230426/343bd971/attachment.htm>