On 9/6/21 5:05 pm, Christian Mauderer wrote: > On 09/06/2021 01:52, Chris Johns wrote: >> On 8/6/21 8:26 pm, Sebastian Huber wrote: >>> On 08/06/2021 05:07, Chris Johns wrote: >>>> On 7/6/21 6:40 pm, Christian Mauderer wrote:> I think the Options don't >>>> need >>>> documentation changes because the options in the >>>>> waf based build system are now documented directly in the yaml files and >>>>> printed >>>>> if you generate the default config. >>>> Hmm I am not sure I agree with the premise the YAML is the documentation. >>>> The >>>> user manual exists for this purpose and user wanting to explore RTEMS would >>>> look >>>> there rather than cloning the repo, running commands etc. >>>> >>>> I accept the current defaults etc work flow is a good place to start for >>>> the >>>> waf >>>> conversion project but we need to do a lot more to make accessing the YAML >>>> easier. The wscript contains the only rtems.git repo means to read the >>>> YAML and >>>> the pickled data and that limits how we can change and evolve this. >>> >>> We could use rtems-central to generate sections for the user manual from the >>> build specification. This would be similar to the generation of the >>> glossaries, >>> application configuration option documentation, and the directive >>> documentation. >> >> Of course we could use it and there are a number of other possible ways we do >> this as well without that repo. The rtems-central repo and work flows have >> clear >> and defined boundary we have put in place for very good reasons. A move that >> way >> would be considered creep. >> >> Chris > > Hello Chris, > > Gedare mentioned that he is OK with the one-line-command in the manual that > shows the user how he gets the options (see > https://lists.rtems.org/pipermail/devel/2021-June/067627.html). Is that OK for > you too? If yes, that would be my preferred solution and you can ignore the > remaining part of the mail.
Yes this is fine. I am happy with something until we can automate. > If not: I'm OK to automate or at least semi-automate the process of generating > that part of the manual because I think it's an improvement. I'm not OK with a > manual step because it increases the maintenance effort and the time I have to > invest on _every_ commit that is vaguely similar to this one. That would mean > more frustration for me and less time that I have for other stuff. > > I can accept that you don't want that kind of automation in rtems-central. > What > would be your preferred solution and location for that kind of automation? Honestly I am not sure. Nothing is a perfect fit and it is an exercise in the less of the evils. I would like to see the python support used in `wscript` being made available as a python module in rtems.git but Sebastian says there is support in rtems-central but that is still not an option. Until I have time to look more I do not know. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel