Darren J Moffat wrote: > 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. > > Could we update the LINT.c definition in $SRC/Makefile.master to always > add in -I$(SPRO_VROOT)/lint/include > > Why wouldn't that work ?
This was proposed in 4393089, and was one of my earlier suggestions. I think the general objections are that we're embedding private knowledge of devpro internals. I know that we're only shadow compiling, not shadow linting, but I'm still loathe to introduce product-specific info like this into our command lines. --Mark
