Re: [PATCH] spec/pkgconfig: Allow builds to override headers
On 1/10/2022 6:30 am, Kinsey Moore wrote: > On 9/29/2022 16:19, Chris Johns wrote: >> On 29/9/22 11:24 pm, Kinsey Moore wrote: >>> On 9/28/2022 19:03, Chris Johns wrote: On 29/9/2022 7:13 am, Kinsey Moore wrote: > This allows any builds targeting an installed RTEMS BSP to override > headers in the installed BSP reliably, including headers previously > installed by that or other builds. This includes applications, network > stacks, libraries, and any other builds. I am a little confused by these comments. This change effects the generated .pc file for a BSP so it is only used once it is installed. >>> Correct, this is a fix for things like rtems-libbsd and rtems-lwip that >>> allows >>> them to build correctly even if there are existing conflicting >>> installations of >>> that library already installed in the BSP install. >> So this is a change to aid developers of these packages who use a single >> prefix >> for the tools, BSP and packages? I split the install paths up and that avoids >> the problem. > I guess I'm conflating a couple of different problems here. I'll take a closer > look at how things behave when there is a separate installation path. I just delete the effect piece. This is not the only reason to separate the paths. Cleaning the builds away is an important test. We have been caught a few times over the years. An install should update the headers at the same time the .pc is installed and made available so what is old or previous? What are the "builds targeting" you refer too? >>> "builds targeting an installed RTEMS BSP" refers to any external build that >>> uses >>> installed RTEMS headers and libraries. These external builds can install >>> their >>> own files in the BSP install. >> Is this install or reinstall? > The issues happen on reinstall since there is an existing header that has a > higher priority in the include search paths than the local search paths. OK I think defining the include search of RTEMS BSP and any vertical stack packages headers installed under the same prefix as system headers seems like the right thing to do. However this change will silence warnings from RTEMS (and installed packages). Is that want we want? >>> What warnings will this silence? >> https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html >> >> This changes the level of warnings we currently have for a specific but >> important group of packages that are based on rtems_waf or use .pc files. I >> think this is important to consider. > > It changes the warning level when used from the installed BSP, but we should > still see these warnings when compiling RTEMS itself and packages compiled > against an installed BSP using the .pc files (via rtems_waf or otherwise) will > still display these warnings in their own headers since they will be used > locally pre-installation. > > There is still the issue of using existing headers in novel ways that could > generate warnings which would be missed due to this change, but even then the > documentation linked claims that macros instanced in non-system-header > locations > are only immune to a small subset of warnings. I think it's worth the change > given that installing additional packages into the installed BSP is common > practice from what I've seen. Yes there is a chance a warning is missed and I cannot answer if that is OK. Maybe Joel would like to comment about this? >>> It shouldn't affect RTEMS builds because RTEMS >>> doesn't use the pkgconfg while building. It still places installed headers >>> before actual system/tools headers in the include hierarchy, so any build >>> errors >>> generated that way should be preserved. >> Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is >> that important? > I hunted for this earlier and missed it. It's apparently in make/custom and > would need to be tweaked as well for consistency. It should be consistent. >> Is this something we should document as mandated for all users of BSP >> installed >> headers? > > It's worth putting it somewhere. Users of the .pc and Makefile.inc won't > notice > or need to care for the most part, but anyone using non-standard external > build > systems will need to know. Agreed Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] spec/pkgconfig: Allow builds to override headers
On 9/29/2022 16:19, Chris Johns wrote: On 29/9/22 11:24 pm, Kinsey Moore wrote: On 9/28/2022 19:03, Chris Johns wrote: On 29/9/2022 7:13 am, Kinsey Moore wrote: This allows any builds targeting an installed RTEMS BSP to override headers in the installed BSP reliably, including headers previously installed by that or other builds. This includes applications, network stacks, libraries, and any other builds. I am a little confused by these comments. This change effects the generated .pc file for a BSP so it is only used once it is installed. Correct, this is a fix for things like rtems-libbsd and rtems-lwip that allows them to build correctly even if there are existing conflicting installations of that library already installed in the BSP install. So this is a change to aid developers of these packages who use a single prefix for the tools, BSP and packages? I split the install paths up and that avoids the problem. I guess I'm conflating a couple of different problems here. I'll take a closer look at how things behave when there is a separate installation path. An install should update the headers at the same time the .pc is installed and made available so what is old or previous? What are the "builds targeting" you refer too? "builds targeting an installed RTEMS BSP" refers to any external build that uses installed RTEMS headers and libraries. These external builds can install their own files in the BSP install. Is this install or reinstall? The issues happen on reinstall since there is an existing header that has a higher priority in the include search paths than the local search paths. I think defining the include search of RTEMS BSP and any vertical stack packages headers installed under the same prefix as system headers seems like the right thing to do. However this change will silence warnings from RTEMS (and installed packages). Is that want we want? What warnings will this silence? https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html This changes the level of warnings we currently have for a specific but important group of packages that are based on rtems_waf or use .pc files. I think this is important to consider. It changes the warning level when used from the installed BSP, but we should still see these warnings when compiling RTEMS itself and packages compiled against an installed BSP using the .pc files (via rtems_waf or otherwise) will still display these warnings in their own headers since they will be used locally pre-installation. There is still the issue of using existing headers in novel ways that could generate warnings which would be missed due to this change, but even then the documentation linked claims that macros instanced in non-system-header locations are only immune to a small subset of warnings. I think it's worth the change given that installing additional packages into the installed BSP is common practice from what I've seen. It shouldn't affect RTEMS builds because RTEMS doesn't use the pkgconfg while building. It still places installed headers before actual system/tools headers in the include hierarchy, so any build errors generated that way should be preserved. Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is that important? I hunted for this earlier and missed it. It's apparently in make/custom and would need to be tweaked as well for consistency. Is this something we should document as mandated for all users of BSP installed headers? It's worth putting it somewhere. Users of the .pc and Makefile.inc won't notice or need to care for the most part, but anyone using non-standard external build systems will need to know. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] spec/pkgconfig: Allow builds to override headers
On 29/9/22 11:24 pm, Kinsey Moore wrote: > On 9/28/2022 19:03, Chris Johns wrote: >> On 29/9/2022 7:13 am, Kinsey Moore wrote: >>> This allows any builds targeting an installed RTEMS BSP to override >>> headers in the installed BSP reliably, including headers previously >>> installed by that or other builds. This includes applications, network >>> stacks, libraries, and any other builds. >> I am a little confused by these comments. This change effects the generated >> .pc >> file for a BSP so it is only used once it is installed. > Correct, this is a fix for things like rtems-libbsd and rtems-lwip that allows > them to build correctly even if there are existing conflicting installations > of > that library already installed in the BSP install. So this is a change to aid developers of these packages who use a single prefix for the tools, BSP and packages? I split the install paths up and that avoids the problem. >> An install should update >> the headers at the same time the .pc is installed and made available so what >> is >> old or previous? What are the "builds targeting" you refer too? > "builds targeting an installed RTEMS BSP" refers to any external build that > uses > installed RTEMS headers and libraries. These external builds can install their > own files in the BSP install. Is this install or reinstall? >> I think defining the include search of RTEMS BSP and any vertical stack >> packages >> headers installed under the same prefix as system headers seems like the >> right >> thing to do. However this change will silence warnings from RTEMS (and >> installed >> packages). Is that want we want? > > What warnings will this silence? https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html This changes the level of warnings we currently have for a specific but important group of packages that are based on rtems_waf or use .pc files. I think this is important to consider. > It shouldn't affect RTEMS builds because RTEMS > doesn't use the pkgconfg while building. It still places installed headers > before actual system/tools headers in the include hierarchy, so any build > errors > generated that way should be preserved. Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is that important? Is this something we should document as mandated for all users of BSP installed headers? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] spec/pkgconfig: Allow builds to override headers
On 9/28/2022 19:03, Chris Johns wrote: On 29/9/2022 7:13 am, Kinsey Moore wrote: This allows any builds targeting an installed RTEMS BSP to override headers in the installed BSP reliably, including headers previously installed by that or other builds. This includes applications, network stacks, libraries, and any other builds. I am a little confused by these comments. This change effects the generated .pc file for a BSP so it is only used once it is installed. Correct, this is a fix for things like rtems-libbsd and rtems-lwip that allows them to build correctly even if there are existing conflicting installations of that library already installed in the BSP install. An install should update the headers at the same time the .pc is installed and made available so what is old or previous? What are the "builds targeting" you refer too? "builds targeting an installed RTEMS BSP" refers to any external build that uses installed RTEMS headers and libraries. These external builds can install their own files in the BSP install. I think defining the include search of RTEMS BSP and any vertical stack packages headers installed under the same prefix as system headers seems like the right thing to do. However this change will silence warnings from RTEMS (and installed packages). Is that want we want? What warnings will this silence? It shouldn't affect RTEMS builds because RTEMS doesn't use the pkgconfg while building. It still places installed headers before actual system/tools headers in the include hierarchy, so any build errors generated that way should be preserved. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] spec/pkgconfig: Allow builds to override headers
On 29/9/2022 7:13 am, Kinsey Moore wrote:
> This allows any builds targeting an installed RTEMS BSP to override
> headers in the installed BSP reliably, including headers previously
> installed by that or other builds. This includes applications, network
> stacks, libraries, and any other builds.
I am a little confused by these comments. This change effects the generated .pc
file for a BSP so it is only used once it is installed. An install should update
the headers at the same time the .pc is installed and made available so what is
old or previous? What are the "builds targeting" you refer too?
I think defining the include search of RTEMS BSP and any vertical stack packages
headers installed under the same prefix as system headers seems like the right
thing to do. However this change will silence warnings from RTEMS (and installed
packages). Is that want we want?
Chris
> ---
> spec/build/bsps/pkgconfig.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index a9462fcc95..8a3c3677a4 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -22,7 +22,7 @@ content: |
>Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
>Version: ${RTEMS_VERSION}
>Description: RTEMS BSP ${ARCH}/${BSP_NAME}
> - Cflags: $${ABI_FLAGS} -I$${includedir}
> + Cflags: $${ABI_FLAGS} -isystem$${includedir}
>Ldflags: -B$${libdir} ${PKGCONFIG_LDFLAGS}
>Libs: -B$${libdir} ${PKGCONFIG_LDFLAGS}
> copyrights:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
