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