[PATCH] build: Add PROGRAM_PREFIX option

[Sebastian Huber]

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.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/