Douglas Walls wrote: > Hi Mark, > > Apologies for the delayed response
No problem, thanks for the additional info. > 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. This wasn't just an excerpt, it's ALL the documentation for the directive. :) Is every product that's part of the C compiler guaranteed to provide [sys/]note.h? If not, then how does #include_next behave if the referenced file does not exist anywhere else on the include search path? > 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 think the approach this thread has been talking through of specifying > the compiler include directories make sense. The compiler include > directories > are conceptually a part of the default include directories. The > compiler has > include files that are meant to interpose on system headers in > /usr/include. > So during the ON builds where compilation commands use -I to specify a > directory > containing header files that are meant to interpose on /usr/include header > file, it makes sense to have a -I<path_to_SunStudio>/prod/include/lint > and -I<path_to_SunStudio>/prod/include/cc as appropriate preceeding the > -I flag specifying the interposing /usr/include header files. Ah! That's interesting, it suggests that the solution we've been discussing is not quite complete. Though it's harmless, because the current SS12/prod/include/cc trees mirror the no-op assignments in the ON default. --Mark > Mark J. Nelson wrote: >> Charles Binford wrote: >>> I've been doing some reading in bugster, the CRs you mentioned and >>> several other "see also" bugs. Looks like this bug has a history! >>> Obviously I still consider it a bug that needs to be fix since I wasted >>> close to a day trying to figure why NOTE(xxx) didn't work as >>> advertised. The suggestion to change Makefile.master is similar to what >>> was suggested in 439089. I don't pretend to understand all of the ins >>> and outs of the issue (being new to the ON development environment) but >>> there seems to be some historical resistance to that general direction. >> >> Yeah, I poked a bit more. That suggestion does lead to some valid >> objections. >> >>> Has there been consideration to just eliminating the lint specific >>> version of note.h and just combining its logic into the standard >>> /usr/include/ version under #ifdef? The lint options in the makefile >>> could set define (unless there already is some define implicitly set >>> while lint is executing?). This approach would address one of the key >>> complaints in the comments of 4503120, namely that developers shouldn't >>> be required to understand how the lint/note mechanism works by including >>> some special, version specific include directory, unless of course it is >>> inadvertently overridden by the environment the developer is forced >>> into. By combining the no-op version and lint-functional version of >>> note.h into the same file, under #ifdef control the interaction of the >>> compile vs. lint functionality of note.h is clear and evident to all. >>> >>> comments? >> >> Oof. I cc'd Douglas Walls, in case he has any suggestions, or to >> correct any potential errors. >> >> I don't like taking the product-specific contents into the generic files. >> >> I believe that the problem is insufficient flexibility in specifying >> include directives to the tools. >> >> Because the ON build provides only a partial overlay of /usr/include, >> we cannot use the -YI,dir to change the default search path. This >> would work for all of the header files that are part of ON, but we >> would never find anything else from /usr/include. >> >> So we use -Idir to specify the proto area of our build workspace, so >> the proto area takes precedence over /usr/include on the build >> machine. But it ALSO takes precedence over "the directories for >> compiler-provided C++ header files, ANSI C header files, and >> special-purpose files." >> >> So lint never finds note.h (or sys/note.h) from DevPro. Instead, it >> gets the empty defs for NOTE() (or _NOTE()) from the proto area. >> >> Douglas, is there any way to specify multiple, default search paths? >> >> Charles, failing that, I think the following might satisfy folks: >> >> - change the ON build so that note.h and sys/note.h are NOT installed >> into the proto area (modifying the install_h targets in usr/src/head >> and usr/src/uts/common/sys, I think). >> >> - modify usr/src/pkgdefs/SUNWhea/Makefile to source these files from >> an alternate location. >> >> - figure out whether or note bfu.sh needs to be modified to provide >> these files. >> >> ? >> >> --Mark >> >> >>> Thanks, >>> Charles Binford >>> >>>>> That sounds like our old friend: CR 4393089. >>>>> >>>>> It's oft-reported. See CR 4875943 for a more modern copy. >>>> Of course. >>>> >>>> So now those that failed to remember the past (or, more accurately, >>>> that never knew about it in the first place) have repeated it. As >>>> they were doomed to do. >>>> >>>> The ENVCPPFLAGS[1-4] are designed to pick stuff up out of parent >>>> proto, and aren't a good place to fix this. >>>> >>>> Charles, you can try something like this: >>>> >>>> In usr/src/Makefile.master, change the definition of CPPFLAGS.master >>>> to read >>>> >>>>> CPPFLAGS.master=$(DTEXTDOM) $(DTS_ERRNO) $(LINTONLYCPPFLAGS) \ >>>>> $(ENVCPPFLAGS1) $(ENVCPPFLAGS2) $(ENVCPPFLAGS3) >>>>> $(ENVCPPFLAGS4) >>>> ...and then in your makefile, add: >>>> >>>>> lint := LINTONLYCPPFLAGS= -I$(SPRO_VROOT)/prod/include/lint >>>> Frankly, it's ugly, and it may break with compiler changes. And >>>> probably the definition of LINTONLYCPPFLAGS belongs in >>>> Makefile.master, for just that reason, but since it should be >>>> conditionally assigned only for the lint target, that seems somewhat >>>> crappy. At least right now, it's safe; the only thing therein is >>>> note.h and sys/note.h. And I checked that it works as expected. >>>> >>>> Can't really win here, other than perhaps to just use the >>>> deprecated-but-still-functional comment forms. Doesn't help with >>>> sys/queue.h. >>>> >>>> Or turn off CONSTCOND in your LINTFLAGS, like James McPherson >>>> suggested originally. >>>> >>>> --Mark >>>> >>
