On Wed, Apr 26, 2023 at 3:58 PM Gedare Bloom <ged...@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.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
