Hi Eric, On 12 Oct 2010, at 08:54, Eric Blake wrote: > On 10/11/2010 07:39 PM, Gary V. Vaughan wrote: >> There are only two options to make both cases behave the same - >> >> 1. always hardcode the full path to the system header, even on machines >> with include_next support; > > (1) is not viable. If a system header itself uses include_next, then we MUST > include that header via system_include, or the nested include_next tries to > include the same absolute name (itself) instead of its intended target. > That's why we had to start using include_next throughout gnulib in the first > place.
Yuck :( Then I believe the only viable option to provide stable support for multiple gnulib directories in a single tree is to add a switch to gnulib-tool to rewrite gnulib #include_next lines on import, so that both types of compilers include header files in the same order. It's certainly doable, but it's going to be finicky and easy to break. I believe this is the problem Bruce was thinking about (and which I dismissed prematurely.. sorry Bruce!) with symbols in installed gnulib headers from libposix clashing with non-libposix gnulib headers in a gnulib client project that also uses libposix... perhaps more patches like Bruno's patch from earlier in this thread will also be required. Cheers, -- Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
