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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel