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.

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?

Best regards

Christian
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to