Re: [PATCH] build: Add PROGRAM_PREFIX option
On 10/8/2023 3:06 pm, Sebastian Huber wrote: > On 10.08.23 03:13, Chris Johns wrote: >> >> On 9/8/2023 7:12 pm, Sebastian Huber wrote: >>> On 09.08.23 11:10, Cedric Berger wrote: On 09.08.23 10:51, Sebastian Huber wrote: > We could add some text to the option description: > > # Defines the program prefix of tools (compiler, assembler, linker). > # This option may be used to build RTEMS with a vendor tool suite. > # Please note that using tool suites not provided by the RTEMS Project > # may not work as expected. If the goal of that comment it to prevent "fielding support related questions", I doubt that writing "may not work as expected" will have the desired effect... >>> I am open for alternative wordings. >>> >> # Defines the program prefix of tools (compiler, assembler, linker) used >> # to build RTEMS. This option may be used to build RTEMS with a vendor >> # tool suite. Please note, support issues related to using this option with >> # vendor tool suites should be directed to the vendor of the tools. > > Sounds good, do you check it in? I have not. Are you able to? If so please feel free to push the change as approved. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 10.08.23 03:13, Chris Johns wrote: On 9/8/2023 7:12 pm, Sebastian Huber wrote: On 09.08.23 11:10, Cedric Berger wrote: On 09.08.23 10:51, Sebastian Huber wrote: We could add some text to the option description: # Defines the program prefix of tools (compiler, assembler, linker). # This option may be used to build RTEMS with a vendor tool suite. # Please note that using tool suites not provided by the RTEMS Project # may not work as expected. If the goal of that comment it to prevent "fielding support related questions", I doubt that writing "may not work as expected" will have the desired effect... I am open for alternative wordings. # Defines the program prefix of tools (compiler, assembler, linker) used # to build RTEMS. This option may be used to build RTEMS with a vendor # tool suite. Please note, support issues related to using this option with # vendor tool suites should be directed to the vendor of the tools. Sounds good, do you check it in? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 9/8/2023 7:12 pm, Sebastian Huber wrote: > On 09.08.23 11:10, Cedric Berger wrote: >> On 09.08.23 10:51, Sebastian Huber wrote: >>> We could add some text to the option description: >>> >>> # Defines the program prefix of tools (compiler, assembler, linker). >>> # This option may be used to build RTEMS with a vendor tool suite. >>> # Please note that using tool suites not provided by the RTEMS Project >>> # may not work as expected. >> >> If the goal of that comment it to prevent "fielding support related >> questions", I doubt that writing "may not work as expected" will have the >> desired effect... > > I am open for alternative wordings. > # Defines the program prefix of tools (compiler, assembler, linker) used # to build RTEMS. This option may be used to build RTEMS with a vendor # tool suite. Please note, support issues related to using this option with # vendor tool suites should be directed to the vendor of the tools. ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 09.08.23 11:10, Cedric Berger wrote: On 09.08.23 10:51, Sebastian Huber wrote: We could add some text to the option description: # Defines the program prefix of tools (compiler, assembler, linker). # This option may be used to build RTEMS with a vendor tool suite. # Please note that using tool suites not provided by the RTEMS Project # may not work as expected. If the goal of that comment it to prevent "fielding support related questions", I doubt that writing "may not work as expected" will have the desired effect... I am open for alternative wordings. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 09.08.23 10:51, Sebastian Huber wrote: We could add some text to the option description: # Defines the program prefix of tools (compiler, assembler, linker). # This option may be used to build RTEMS with a vendor tool suite. # Please note that using tool suites not provided by the RTEMS Project # may not work as expected. If the goal of that comment it to prevent "fielding support related questions", I doubt that writing "may not work as expected" will have the desired effect... Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 09.08.23 03:26, Chris Johns wrote:
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?
We could add some text to the option description:
# Defines the program prefix of tools (compiler, assembler, linker).
# This option may be used to build RTEMS with a vendor tool suite.
# Please note that using tool suites not provided by the RTEMS Project
# may not work as expected.
PROGRAM_PREFIX = ${ARCH}-rtems${__RTEMS_MAJOR__}-
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?
The Gaisler tools were configured like this:
Configured with:
/scratch/jenkins/workspace/RCC_master-KM5WEZV2QBPWA3KWTLID2LONMQ6KHXQSKK2LENARD3XKNAOB5V6Q/toolchain/gcc/configure
--target=sparc-gaisler-rtems5 --host= --disable-shared --with-newlib
--enable-threads --enable-languages=c,c++ --disable-nls --disable-plugin
--enable-lto --enable-libgomp --prefix=/opt/rcc-1.3.1-gcc
--with-cpu=leon3 --enable-version-specific-runtime-libs --disable-libcc1
--disable-libstdcxx-pch --disable-win32-registry --disable-decimal-float
--disable-install-libiberty --disable-fixed-point --with-gnu-as
--with-sysroot=/opt/rcc-1.3.1-gcc/sparc-gaisler-rtems5
--without-included-gettext --enable-newlib-io-c99-formats
--enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8
Re: [PATCH] build: Add PROGRAM_PREFIX option
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
Re: [PATCH] build: Add PROGRAM_PREFIX option
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.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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. 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. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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. > 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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. 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. I have problems to send test reports by e-mail: Anything Amar or I can help with? Chris -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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? > I have problems to send test reports by e-mail: Anything Amar or I can help with? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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. 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.
I have problems to send test reports by e-mail:
Passed:617
Failed: 2
User Input: 6
Expected Fail: 2
Indeterminate: 0
Benchmark: 3
Timeout: 0
Test too long: 0
Invalid: 0
Wrong Version: 0
Wrong Build: 0
Wrong Tools: 0
Wrong Header:0
--
Total: 630
Failures:
dl11.exe
psxkey07.exe
User Input:
dl10.exe
monitor.exe
termios.exe
top.exe
capture.exe
fileio.exe
Expected Fail:
dl06.exe
psxfenv01.exe
Benchmark:
dhrystone.exe
whetstone.exe
linpack.exe
Average test time: 0:00:00.214642
Testing time : 0:02:15.224347
Traceback (most recent call last):
File "/opt/rtems/6/bin/rtems-test", line 42, in
tester.rt.test.run(sys.argv)
File "/opt/rtems/6/share/rtems/tester/rt/test.py", line 544, in run
mail.send(to_addr, subject, os.linesep.join(body))
File "/opt/rtems/6/share/rtems/rtemstoolkit/mailer.py", line 215, in send
s.sendmail(from_addr, [to_addr], msg)
File "/usr/lib64/python3.6/smtplib.py", line 866, in sendmail
(code, resp) = self.mail(from_addr, esmtp_opts)
File "/usr/lib64/python3.6/smtplib.py", line 539, in mail
self.putcmd("mail", "FROM:%s%s" % (quoteaddr(sender), optionlist))
File "/usr/lib64/python3.6/smtplib.py", line 153, in quoteaddr
if addrstring.strip().startswith('<'):
AttributeError: 'NoneType' object has no attribute 'strip'
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 02.08.23 13:53, Karel Gardas wrote: A bit off-topic. On 8/2/23 10:39, Sebastian Huber wrote: Yes, but this would be another patch and it is a bit more work since you have to test the clang support. Is building with clang already supported? I'm curious since this is something I'd like to test locally too but neither code nor tickets give me any hope on it. Hence asking directly. There is some support to build with clang, but I guess this is not regularly tested/used. You can test it with: [riscv/rv64imafdc] COMPILER = clang However, this quickly fails with: [ 1/1427] Compiling bsps/shared/dev/serial/mc68681_reg2.c 15:16:15 runner ['/usr/bin/clang', '-MMD', '-Wall', '-Wmissing-prototypes', '-Wimplicit-function-declaration', '-Wstrict-prototypes', '-Wnested-externs', '--target=riscv64-unknown-rtems6', '-march=rv64imafdc', '-mabi=lp64d', '-mcmodel=medany', '-O2', '-g', '-fdata-sections', '-ffunction-sections', '-Icpukit/include', '-I/home/EB/sebastian_h/src/rtems/cpukit/include', '-Icpukit/score/cpu/riscv/include', '-I/home/EB/sebastian_h/src/rtems/cpukit/score/cpu/riscv/include', '-Ibsps/include', '-I/home/EB/sebastian_h/src/rtems/bsps/include', '-Ibsps/riscv/include', '-I/home/EB/sebastian_h/src/rtems/bsps/riscv/include', '-Ibsps/riscv/riscv/include', '-I/home/EB/sebastian_h/src/rtems/bsps/riscv/riscv/include', '/home/EB/sebastian_h/src/rtems/bsps/shared/dev/serial/mc68681_reg2.c', '-c', '-o/tmp/sh/b-rtems/riscv/rv64imafdc/bsps/shared/dev/serial/mc68681_reg2.c.1.o', '-DHAVE_CONFIG_H=1'] In file included from /home/EB/sebastian_h/src/rtems/bsps/shared/dev/serial/mc68681_reg2.c:39: In file included from /home/EB/sebastian_h/src/rtems/bsps/shared/dev/serial/mc68681_reg.c:35: In file included from /home/EB/sebastian_h/src/rtems/cpukit/include/rtems.h:59: In file included from /home/EB/sebastian_h/src/rtems/cpukit/include/rtems/config.h:62: In file included from /home/EB/sebastian_h/src/rtems/cpukit/include/rtems/rtems/config.h:62: /home/EB/sebastian_h/src/rtems/cpukit/include/rtems/rtems/tasks.h:62:10: fatal error: 'sys/cpuset.h' file not found #include ^~ 1 error generated. You still need Newlib somehow and also the compiler-rt library for your target. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
A bit off-topic. On 8/2/23 10:39, Sebastian Huber wrote: Yes, but this would be another patch and it is a bit more work since you have to test the clang support. Is building with clang already supported? I'm curious since this is something I'd like to test locally too but neither code nor tickets give me any hope on it. Hence asking directly. Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 2/8/2023 6:56 pm, Sebastian Huber wrote:
> On 02.08.23 10:50, Chris Johns wrote:
>> On 2/8/2023 6:39 pm, Sebastian Huber wrote:
>>> On 02.08.23 10:33, Chris Johns wrote:
> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
> index ac395f2f02..08fc75a8b9 100644
> --- a/spec/build/bsps/makeinc.yml
> +++ b/spec/build/bsps/makeinc.yml
> @@ -16,14 +16,14 @@ content: |
> prefix = ${PREFIX}
> exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
> - CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
> - CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> - AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
> - AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> - NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
> - LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> - SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
> - OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> + CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
> + CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
Is it worth doing the same to gcc and g++ as well so these can be replaced
as
well?
>>> Yes, but this would be another patch and it is a bit more work since you
>>> have to
>>> test the clang support.
>>>
> + AS_FOR_TARGET = ${PROGRAM_PREFIX}as
> + AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
> + NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
> + LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
> + SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
> + OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
Where is PROGRAM_PFREFIX set?
>>> It is a new configuration option:
>>>
>>> [sparc/gr740]
>>> PROGRAM_PREFIX = ${ARCH}-rtems7-
>>>
>> Yes, but if these files are installed does it need to be in defined in those
>> files?
>
> The option substitution takes place before the files are installed. For
> example:
Ah OK. I did not pick that up in the patch.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 02.08.23 10:50, Chris Johns wrote:
On 2/8/2023 6:39 pm, Sebastian Huber wrote:
On 02.08.23 10:33, Chris Johns wrote:
diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
index ac395f2f02..08fc75a8b9 100644
--- a/spec/build/bsps/makeinc.yml
+++ b/spec/build/bsps/makeinc.yml
@@ -16,14 +16,14 @@ content: |
prefix = ${PREFIX}
exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
- CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
- CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
- AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
- AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
- NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
- LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
- SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
- OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
+ CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
+ CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
Is it worth doing the same to gcc and g++ as well so these can be replaced as
well?
Yes, but this would be another patch and it is a bit more work since you have to
test the clang support.
+ AS_FOR_TARGET = ${PROGRAM_PREFIX}as
+ AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
+ NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
+ LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
+ SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
+ OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
Where is PROGRAM_PFREFIX set?
It is a new configuration option:
[sparc/gr740]
PROGRAM_PREFIX = ${ARCH}-rtems7-
Yes, but if these files are installed does it need to be in defined in those
files?
The option substitution takes place before the files are installed. For
example:
cat /opt/rtems/6/arm-rtems6/xilinx_zynq_a9_qemu/Makefile.inc
#
# BSP specific settings. To be included in application Makefiles
#
# This support will be removed from RTEMS. Please consider other
# ways to build applications.
#
RTEMS_API = 6
RTEMS_CPU = arm
RTEMS_BSP = xilinx_zynq_a9_qemu
prefix = /opt/rtems/6
exec_prefix = ${prefix}/arm-rtems6
CC_FOR_TARGET = arm-rtems7-gcc
CXX_FOR_TARGET = arm-rtems7-g++
AS_FOR_TARGET = arm-rtems7-as
AR_FOR_TARGET = arm-rtems7-ar
NM_FOR_TARGET = arm-rtems7-nm
LD_FOR_TARGET = arm-rtems7-ld
SIZE_FOR_TARGET = arm-rtems7-size
OBJCOPY_FOR_TARGET = arm-rtems7-objcopy
CC= $(CC_FOR_TARGET)
CXX= $(CXX_FOR_TARGET)
AS= $(AS_FOR_TARGET)
LD= $(LD_FOR_TARGET)
NM= $(NM_FOR_TARGET)
AR= $(AR_FOR_TARGET)
SIZE= $(SIZE_FOR_TARGET)
OBJCOPY= $(OBJCOPY_FOR_TARGET)
export CC
export CXX
export AS
export LD
export NM
export AR
export SIZE
export OBJCOPY
RTEMS_ROOT ?= $(prefix)
PROJECT_ROOT = $(RTEMS_ROOT)
RTEMS_CUSTOM = $(RTEMS_ROOT)/make/custom/$(RTEMS_BSP).cfg
RTEMS_SHARE = $(RTEMS_ROOT)/share/rtems$(RTEMS_API)
RTEMS_USE_OWN_PDIR = no
RTEMS_HAS_POSIX_API =
RTEMS_HAS_ITRON_API = no
RTEMS_HAS_CPLUSPLUS = yes
export RTEMS_BSP
export RTEMS_CUSTOM
export PROJECT_ROOT
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 2/8/2023 6:39 pm, Sebastian Huber wrote:
> On 02.08.23 10:33, Chris Johns wrote:
>>> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
>>> index ac395f2f02..08fc75a8b9 100644
>>> --- a/spec/build/bsps/makeinc.yml
>>> +++ b/spec/build/bsps/makeinc.yml
>>> @@ -16,14 +16,14 @@ content: |
>>> prefix = ${PREFIX}
>>> exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
>>> - CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
>>> - CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
>>> - AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
>>> - AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
>>> - NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
>>> - LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
>>> - SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
>>> - OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
>>> + CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
>>> + CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
>> Is it worth doing the same to gcc and g++ as well so these can be replaced as
>> well?
>
> Yes, but this would be another patch and it is a bit more work since you have
> to
> test the clang support.
>
>>
>>> + AS_FOR_TARGET = ${PROGRAM_PREFIX}as
>>> + AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
>>> + NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
>>> + LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
>>> + SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
>>> + OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
>> Where is PROGRAM_PFREFIX set?
>
> It is a new configuration option:
>
> [sparc/gr740]
> PROGRAM_PREFIX = ${ARCH}-rtems7-
>
Yes, but if these files are installed does it need to be in defined in those
files?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 2/8/2023 6:42 pm, Sebastian Huber wrote: > On 02.08.23 10:40, Chris Johns wrote: >> On 2/8/2023 6:33 pm, Chris Johns wrote: >>> On 2/8/2023 3:49 pm, Sebastian Huber wrote: Replace --rtems-version with a PROGRAM_PREFIX option. This allows also the use of vendor tools.> --- >> One further thing to consider is if PROGRAM_PREFIX could clash with something >> else in a user's environment because it is not in any RTEMS name space, ie >> RTEMS_PROGRAM_PREFIX? > > No, this could not clash. The options have their own namespace. What about Makefile.inc when installed? 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 02.08.23 10:40, Chris Johns wrote: On 2/8/2023 6:33 pm, Chris Johns wrote: On 2/8/2023 3:49 pm, Sebastian Huber wrote: Replace --rtems-version with a PROGRAM_PREFIX option. This allows also the use of vendor tools.> --- One further thing to consider is if PROGRAM_PREFIX could clash with something else in a user's environment because it is not in any RTEMS name space, ie RTEMS_PROGRAM_PREFIX? No, this could not clash. The options have their own namespace. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 2/8/2023 6:33 pm, Chris Johns wrote: > On 2/8/2023 3:49 pm, Sebastian Huber wrote: >> Replace --rtems-version with a PROGRAM_PREFIX option. This allows also >> the use of vendor tools.> --- One further thing to consider is if PROGRAM_PREFIX could clash with something else in a user's environment because it is not in any RTEMS name space, ie RTEMS_PROGRAM_PREFIX? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 02.08.23 10:33, Chris Johns wrote:
diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
index ac395f2f02..08fc75a8b9 100644
--- a/spec/build/bsps/makeinc.yml
+++ b/spec/build/bsps/makeinc.yml
@@ -16,14 +16,14 @@ content: |
prefix = ${PREFIX}
exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
- CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
- CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
- AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
- AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
- NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
- LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
- SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
- OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
+ CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
+ CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
Is it worth doing the same to gcc and g++ as well so these can be replaced as
well?
Yes, but this would be another patch and it is a bit more work since you
have to test the clang support.
+ AS_FOR_TARGET = ${PROGRAM_PREFIX}as
+ AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
+ NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
+ LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
+ SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
+ OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
Where is PROGRAM_PFREFIX set?
It is a new configuration option:
[sparc/gr740]
PROGRAM_PREFIX = ${ARCH}-rtems7-
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 2/8/2023 3:49 pm, Sebastian Huber wrote:
> Replace --rtems-version with a PROGRAM_PREFIX option. This allows also
> the use of vendor tools.> ---
> spec/build/bsps/makeinc.yml| 16
> spec/build/bsps/maketarget.yml | 22 +++---
> spec/build/bsps/optobjcopy.yml | 2 +-
> spec/build/cpukit/cpuopts.yml | 2 ++
> spec/build/cpukit/optgcc.yml | 8
> spec/build/cpukit/optprogramprefix.yml | 18 ++
> spec/build/testsuites/ada/optgnat.yml | 2 +-
> wscript| 24 ++--
> 8 files changed, 47 insertions(+), 47 deletions(-)
> create mode 100644 spec/build/cpukit/optprogramprefix.yml
>
> diff --git a/spec/build/bsps/makeinc.yml b/spec/build/bsps/makeinc.yml
> index ac395f2f02..08fc75a8b9 100644
> --- a/spec/build/bsps/makeinc.yml
> +++ b/spec/build/bsps/makeinc.yml
> @@ -16,14 +16,14 @@ content: |
>prefix = ${PREFIX}
>exec_prefix = $${prefix}/${ARCH}-rtems${__RTEMS_MAJOR__}
>
> - CC_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
> - CXX_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> - AS_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
> - AR_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> - NM_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
> - LD_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> - SIZE_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
> - OBJCOPY_FOR_TARGET = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> + CC_FOR_TARGET = ${PROGRAM_PREFIX}gcc
> + CXX_FOR_TARGET = ${PROGRAM_PREFIX}g++
Is it worth doing the same to gcc and g++ as well so these can be replaced as
well?
> + AS_FOR_TARGET = ${PROGRAM_PREFIX}as
> + AR_FOR_TARGET = ${PROGRAM_PREFIX}ar
> + NM_FOR_TARGET = ${PROGRAM_PREFIX}nm
> + LD_FOR_TARGET = ${PROGRAM_PREFIX}ld
> + SIZE_FOR_TARGET = ${PROGRAM_PREFIX}size
> + OBJCOPY_FOR_TARGET = ${PROGRAM_PREFIX}objcopy
Where is PROGRAM_PFREFIX set?
>CC= $$(CC_FOR_TARGET)
>CXX= $$(CXX_FOR_TARGET)
> diff --git a/spec/build/bsps/maketarget.yml b/spec/build/bsps/maketarget.yml
> index 798b64fa22..7a7b0c3d35 100644
> --- a/spec/build/bsps/maketarget.yml
> +++ b/spec/build/bsps/maketarget.yml
> @@ -11,17 +11,17 @@ content: |
>LIBS =
>
>RTEMS_API = ${__RTEMS_MAJOR__}
> - CC = ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc --pipe
> - AS = ${ARCH}-rtems${__RTEMS_MAJOR__}-as
> - AR = ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> - NM = ${ARCH}-rtems${__RTEMS_MAJOR__}-nm
> - LD = ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> - SIZE = ${ARCH}-rtems${__RTEMS_MAJOR__}-size
> - STRIP = ${ARCH}-rtems${__RTEMS_MAJOR__}-strip
> - OBJCOPY = ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> - RANLIB = ${ARCH}-rtems${__RTEMS_MAJOR__}-ranlib
> -
> - CXX = ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> + CC = ${PROGRAM_PREFIX}gcc --pipe
> + AS = ${PROGRAM_PREFIX}as
> + AR = ${PROGRAM_PREFIX}ar
> + NM = ${PROGRAM_PREFIX}nm
> + LD = ${PROGRAM_PREFIX}ld
> + SIZE = ${PROGRAM_PREFIX}size
> + STRIP = ${PROGRAM_PREFIX}strip
> + OBJCOPY = ${PROGRAM_PREFIX}objcopy
> + RANLIB = ${PROGRAM_PREFIX}ranlib
> +
> + CXX = ${PROGRAM_PREFIX}g++
Same here with setting PROGRAM_PREFIX?
Chris
>
>export CC
>export AS
> diff --git a/spec/build/bsps/optobjcopy.yml b/spec/build/bsps/optobjcopy.yml
> index 3387e23794..63fab08ac6 100644
> --- a/spec/build/bsps/optobjcopy.yml
> +++ b/spec/build/bsps/optobjcopy.yml
> @@ -1,6 +1,6 @@
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-objcopy
> +- set-value: ${PROGRAM_PREFIX}objcopy
> - substitute: null
> - find-program: null
> - env-assign: OBJCOPY
> diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
> index f1b30eec55..1d28ace552 100644
> --- a/spec/build/cpukit/cpuopts.yml
> +++ b/spec/build/cpukit/cpuopts.yml
> @@ -7,6 +7,8 @@ guard: _RTEMS_SCORE_CPUOPTS_H
> include-headers: []
> install-path: ${BSP_INCLUDEDIR}/rtems/score
> links:
> +- role: build-dependency
> + uid: optprogramprefix
> - role: build-dependency
>uid: optgcc
> - role: build-dependency
> diff --git a/spec/build/cpukit/optgcc.yml b/spec/build/cpukit/optgcc.yml
> index 3afb909444..94af494af4 100644
> --- a/spec/build/cpukit/optgcc.yml
> +++ b/spec/build/cpukit/optgcc.yml
> @@ -1,21 +1,21 @@
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-gcc
> +- set-value: ${PROGRAM_PREFIX}gcc
> - substitute: null
> - find-program: null
> - env-assign: AS
> - env-assign: CC
> - env-assign: LINK_CC
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-g++
> +- set-value: ${PROGRAM_PREFIX}g++
> - substitute: null
> - find-program: null
> - env-assign: CXX
> - env-assign: LINK_CXX
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-ar
> +- set-value: ${PROGRAM_PREFIX}ar
> - substitute: null
> - find-program: null
> - env-assign: AR
> -- set-value: ${ARCH}-rtems${__RTEMS_MAJOR__}-ld
> +- se
