bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

[Andy Wingo]

Thank you for thinking about this :)

On Thu 17 Dec 2015 22:43, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> skribis:
>
>> We should be using C_INCLUDE_PATH instead of CPATH, to mark system
>> headers as system headers.  Except that C_INCLUDE_PATH only works for
>> C, so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.
>> And that's the proposal of this bug :)
>
> The intent of this “system header” classification, AIUI, is to not
> bother users with issues in libc headers.

I don't think this is true, for what it's worth :)  If we take FHS
systems to be the de-facto default standard on how things should behave,
-isystem covers all of /usr/include, so in practice it covers not just
libc warnings, but many other warnings, which when you pass -Werror
would then become errors.

I think it's reasonable to suppose that there are many packages out
there that have warnings in their header files for some set of -W
arguments that the package author didn't test.  I specifically remember
getting warnings related to ELF headers for a different project, before
I understood this problem.  On an FHS system of course these problems
are swept under the rug and we don't see them -- no warning, no problem
with -Werror.

It seems to me that just as all packages in /usr/include are marked
"system" on FHS systems, a Guix profile should mark its headers as
"system".

> The problem is that if we use C_INCLUDE_PATH & co., every header in the
> search path, not just libc’s, would now be considered a system header,
> and thus exempt from warnings.  This would be undesirable.

Obviously the best thing would be if there were never any warnings in
the headers exported by projects.  However I think this is unlikely:
warnings evolve over time, and the author of libfoo doesn't choose the
warnings that users of her package enable, and probably doesn't test all
warnings.  Most users, especially users that build on FHS systems, will
never see these warnings anyway.

I think on this question Guix should choose the pragmatic way that lets
users get on with hacking and doesn't detour them into warnings in
headers of packages they use :)

Andy