[PATCH] spec/pkgconfig: Allow builds to override headers

[Chris Johns]

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