Ludovic Courtès <ludo@gnu.org> writes:

> The attached patch does three things:
>
>   1. Fix the order of inputs computed by (@@ (guix build-system gnu)
>      lower) so that implicit inputs come last.  In particular, this
>      ensures that libc headers and kernel headers come last.  All user
>      libraries passed as ‘inputs’ appear before libc, so they can
>      #include_next a libc header.
>
>   2. Add “include/c++” to the list of directories of
>      ‘CPLUS_INCLUDE_PATH’.  This is a not-so-elegant hack; the main
>      purpose here is to make sure the gcc/libstdc++ include directory
>      appears twice in the search path, so that this chain of include
>      works as expected:
>
>        <cstdlib> (GCC): #include_next <stdlib.h>
>        → <stdlib.h> (GCC): #include_next <stdlib.h>
>        → <stdlib.h> (libc)
>
>   3. Switch back to ‘C_INCLUDE_PATH’ & co. instead of ‘CPATH’ (yay!).
>
> I’ve tested it with “guix build coreutils”, which involved building GMP
> with its C++ bindings, making it a rather good test.  However, more
> testing is needed.
>
> There’s potential for breakage in all the places where we’ve manually
> fiddled with C{,PLUS}_INCLUDE_PATH.  I guess we’ll have to review all of
> them.
>
> Since it fixes a rather serious issue for C/C++ developers (they’d
> rather not see warnings about system headers) but also for packaging
> (‘-Werror’ breaks for warnings that shouldn’t be there in the first
> place), I’d like to propose merging it in this ‘core-updates’ cycle.
> But let’s face it: it’ll keep us busy for a bit.  :-)
>
> Thoughts?

The patch looks great to me.  Love how simple your solution was.  The
#include_next issue be confusing and frustrating even for seasoned Guix
developers, so I'm all for getting it in ASAP.

Can you check whether (gnu packages cross-base) can be adjusted in the
same vein?  I.e. go back to CROSS_C_INCLUDE_PATH & co, and dropping the
'treat-glibc-as-system-header' phase from "cross-gcc-arguments".