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 >>
