Fedor Sergeev wrote: > On Fri, Feb 06, 2009 at 03:12:35PM -0800, Douglas Walls wrote: >> Hi Mark, >> >> Apologies for the delayed response >> >> Another idea to explore is to introduce the use of the #include_next >> directive into >> note.h ... something like: >> >> #ifdef __SUNPRO_C >> #include_next <note.h> >> #else >> ... rest of current header body ... >> #endif >> >> Here is what the Sun Studio 12 README says about #include_next directive >> >> Support for the #include_next directive >> >> The C compiler now supports the #include_next directive. The directive >> does not distinguish between <filename> and "filename" inclusion, nor >> does it check that the file you specify has the same name as the current >> file. The compiler looks for the specified file starting with the >> directory in the search path after the one where the current file which >> contains the #include_next directive. >> >> We introduced #include_next support in Sun Studio 12. >> I'd recommend keying off of the __SUNPRO_C macro not the __lint >> macro as other tools like lock_lint and warlock use <note.h>, and >> thus have the same kind of issue. >> >> Though use of #include_next might make sense in the interposing system >> header files specified by the -I directive in the ON builds, >> I suspect #include_next does not belong in /usr/include/sys/note.h, >> as /usr/include is the last directory searched by the compiler and lint. >> >> Sorry there is no way I know of to specify multiple default include paths. > > I did not follow this discussion closely, but -I- option might be a good > way to specify additional "system include" paths. > I believe it should work even together with -YI.
The -I- option doesn't work for us; if we put our proto area usr/include before -I-, then we get the product-specific note.h, but everything else falls through to the system usr/include, which is guaranteed to cause problems. If we put it after, then we haven't solved anything. --Mark
