[PATCH rtems 2/2] bsps/imxrt: Simplify linkcmds and make it flexible

[Chris Johns]

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