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