[PATCH] build: Add PROGRAM_PREFIX option

[Chris Johns]

On 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.

Chris