<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 26, 2023 at 3:58 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is the result of this discussion to use CSafeLoader for now? Or do we<br>
still debate the transition to JSON?<br>
<br>
I see some quirks need to be dealt with as you mentioned with the<br>
multi-line stuff. The yaml is pretty simple to understand and work<br>
with. I've dealt with hand-editing JSON and it's a pain with the<br>
quotes and brackets/braces.<br>
<br>
Since the transition is (apparently) an implementation detail, I don't<br>
actually see that it matters do it now or do it after releasing 6. If<br>
it doesn't change the user experience other than build time, then it<br>
should matter when we do it. In that case, better to be conservative<br>
to avoid rushing to push something this major so close to a release.<br></blockquote><div><br></div><div>I'm going to pile on and cynically say at this point in time, we should be</div><div>focusing on the 6 release and not imagining new sources of churn. I am</div><div>avoiding any opinion that would lead to change at this point in time.</div><div><br></div><div>I will say that with the current waf, I think I understand in principle at least</div><div>some of the high level goals for the user an I am not positive me meet these</div><div>as well as possible even if the implementation approach could be improved.</div><div>And nothing being discussed would improve what I see.</div><div><br></div><div>+ look at the bsp defaults to see what configuration options are available<br></div><div> for a specific BSP family.</div><div><br></div><div>+ write a config.ini that they put under THEIR configuration control<br></div><div><br></div><div>+ possibly "create" a local BSP family variant with that INI file.<br></div><div> Assuming the configuration points exist in the BSP family.</div><div><br></div><div>+ If their variant reflects a generally available board, then add it to<br></div><div> the BSP family as a variant.</div><div><br></div><div>I tried to explain the first three this week in the class and it isn't easy.</div><div>A few observations that have nothing to do with YAML/JSON or even</div><div>carving the settings into stone tablets.</div><div><br></div><div>+ There was discussion that documentation of the BSP options could<br></div><div>be generated from waf/specs. The comments I have seen are not enough</div><div>to do anything useful. The BSP specific ones are usually short and cryptic.</div><div>This is especially true when the setting is a specific hex value for an CPU</div><div>or SoC specific register. One could guess RAM size, base address, or UART </div><div>N present type settings.</div><div><br></div><div>+ The philosophical goals behind the bsp defaults, a user writing an INI file,<br></div><div>the flexibility, etc.are not being communicated. Why do this? What's good </div><div>about it? Why do users care?</div><div><br></div><div>+ If there is discussion of using the configuration INI file to do a custom<br></div><div>BSP variant, I didn't find it while looking for the class. </div><div><br></div><div>The last two could be me not finding something. </div><div><br></div><div>But ultimately we need to cut the 6 release branch. I think we have been</div><div>talking about it over a year now. Let's focus and kill it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Wed, Apr 26, 2023 at 2:30 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> On 26.04.23 00:37, Chris Johns wrote:<br>
> > On 26/4/2023 4:01 am, Sebastian Huber wrote:<br>
> >> We have a fraction of a second if we use the CSafeLoader and no item cache.<br>
> >> Currently we use the SafeLoader which results in about 5 seconds. I would like<br>
> >> to use the build system for more stuff, so this could grow to 10, 15, or more<br>
> >> seconds which then start to get annoying if you work frequently with it.<br>
> > Then please outline what all you have in mind and what the long term plan is<br>
> > then we can consider the overall direction.<br>
><br>
> We work on a prototype to build libbsd, lwip, abseil-cpp, googletest,<br>
> jsoncpp, libsodium, nats.c, protobuf, protobuf-c, utf8_range, cfs,<br>
> zephyr, chip vendor HALs, etc. with the RTEMS build system.<br>
><br>
<br>
This is interesting although it appears to be quite a bit of scope<br>
creep. I guess the intent is to help with traceability of these<br>
projects too?<br>
<br>
-Gedare<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>