[PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 8/8/2023 11:14 pm, Sebastian Huber wrote:
> On 08.08.23 08:06, Chris Johns wrote:
>> n 7/8/2023 4:06 pm, Sebastian Huber wrote:
>>> On 07.08.23 00:25, Chris Johns wrote:
>>>> On 4/8/2023 4:39 pm, Sebastian Huber wrote:
>>>>> On 04.08.23 08:22, Chris Johns wrote:
>>>>>> On 4/8/2023 3:16 pm, Sebastian Huber wrote:
>>>>>>> On 04.08.23 00:27, Chris Johns wrote:
>>>>>>>> On 2/8/2023 6:49 pm, Chris Johns wrote:
>>>>>>>>      > I am concerned about the compatibility to the ecosystem we have.
>>>>>>>> Have you
>>>>>>>> built
>>>>>>>>> all the tests in the testsuite with this value set to something that is
>>>>>>>>> not
>>>>>>>>> RTEMS default? I think a few things will break because of hard coding in
>>>>>>>>> them.
>>>>>>>> I have asked for test results and I have not seen any yet the patch has
>>>>>>>> been
>>>>>>>> merged? The change was not approved my me and is still not approved.
>>>>>>> Sorry I thought it was fine after answering your questions.
>>>>>> All good, I would like to finish the discusion. 🙂
>>>>>>
>>>>>>> Yes, I have tested this with the rtems7 tools. It was possible to build with
>>>>>>> the rtems7 tools
>>>>>>> before, however, the PROGRAM_PREFIX approach is better, since it allows
>>>>>>> also the
>>>>>>> build using vendor tools. We had some fixes for this recently:
>>>>>>>
>>>>>>> https://lists.rtems.org/pipermail/devel/2023-May/075321.html
>>>>>>>
>>>>>>> This is something the user need.
>>>>>> What if a user adds or uses a prefix that does not conform to the standard
>>>>>> format? I am assuming this is possible to do this, eg Gaisler's special
>>>>>> prefix?
>>>>>>
>>>>>> Possible breakage is
>>>>>> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457   ?
>>>>>>
>>>>>> Do we need to document any constraints around this option?
>>>>> There will be always problems left to fix.
>>>> I do not see this as a problem, I see an incomplete change pushed without the
>>>> review being completed.
>>> Sometimes it is not 100% clear when a review is finished.
>> Yes it is all a bit fragile and there is lots of guess work.
>>
>>>>> A basic build and the normal tests
>>>>> work fine with non-standard tools. For the Gaisler tools, you would need:
>>>>>
>>>>> PROGRAM_PREFIX = sparc-gaisler-rtems5-
>>>>>
>>>>> I guess the rld-cc.cpp will also have issues with a clang build.
>>>> Yes it would and libdl is a part of RTEMS and breaking it again is something I
>>>> would like to avoid. I consider the change incomplete because one part says use
>>>> PROGRAM_PREFIX to change the tools prefix however doing so may break other
>>>> parts. There is nothing to warn the user PROGRAM_PREFIX may not work as
>>>> expected.
>>> I don't use vendor tool chains, but it seems that some users would like to use
>>> them. They were supported by the old build system, so a lacking support in the
>>> new build system would be a regression. But if you don't like this change, then
>>> we can also revert the patch.
>> I think the change is fine and I am not suggesting it is reverted. It is not
>> clear to me if more work is needed to complete what this has started because I
>> do not know where we stand with vendor tools.
>>
>> I think supporting vendor tools is something we should consider and either
>> accept it and sort out what is needed or we clearly state vendors are on their
>> own.
>>
>> Supporting vendor tools add something else we need to test and handle but it
>> lets vendors own the tools they create and it is clear to us when a user raises
>> a problem when using them.
> 
> The vendor tools support works now as good or bad as in RTEMS 5. If someone
> wants better support, then he/she should work on it. We can't make everything
> perfect, there are other things left to do for the RTEMS 6 release.

Should we document the extent of what we do support and what is missing?

And yes I agree with your comments however users are often not aware of this and
we end up fielding support related questions. I also do not think we need to do
much to make it work but I am not sure. How do you build gcc with a different
tools prefix?

Chris