> For now ksh93 is not lint clean (it may become "lint" clean with minor > exceptions (silenced via "-erroff=") in the future - if you follow the > evolution of ksh93s- to ksh93s+ you'll notice that _lots_ of cleanup > work (e.g. compiler warnings, lint warnings, issues reported by Rational > Purify and "dbx -check access", Klockwork.com did us a favour and ran > their tools over the sources and reported the results back to > David&&Glenn etc.) has been done, not only for ksh93 but for the whole > AST codebase (which rivals OS/Net in size)), therefore I followed the > "perl" example. > > I've did a quick search through my mightly email archive... AFAIK the > original reason for doing it was to avoid that people do a "make lint ; > hit errors and then randomly start patching the sources at the next code > cleanup party" ...
If your goal is to prevent anyone from fixing lint problems in there until we pull in new upstream changes that have them, then I'm OK with that. It would be good to comment that accordingly. > Roger: > > I recommend, given the complexity of the proposed directory > hierarchy, to just put mapfile-vers in the top-level directory > (Option 2. above). There are plenty of other libraries that > do this. In general, it's quite rare to have the "common" mapfile-vers be in a different directory from the library's sources. > > But if you really believe it simpifies updates, I'm OK with it > > -- just make that clear in the comment > > Any suggestions for the comment (I hoped the current one was clear > enougth) ? Would... > -- snip -- > # mapfile-vers does not live in common/ because this directory > # is for AST code only (e.g. to make automated code updates > # easier) > -- snip -- > ... be Ok ? Yes, or maybe just: # mapfile-vers does not live with the sources to make automated code # updates easier. > In theory we could add something like a "C99XPG6ENABLE" value (which > expands to "$(C99_ENABLE) -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1") for > "C99MODE" - would that be usefull (please read the comment in > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/getconf/Makefile > about XPG6MODE, this stuff is slightly tricky and has some holes with > poisoned spikes at the bottom... ;-( ) ? It would be useful but not required. In general, the problem with putting preprocessor directives in macros other than CPPFLAGS is that other build entities that use preprocessor directives (like lint) end up missing those directives. In this particular case, C99LMODE is derived from C99MODE so at least lint will pick up the defines, but there may be other cases (also, I don't see any precedent for putting preprocessor directives into the C99MODE macro.) > > Do you really often navigate into "pics"? Why? In any case, I am against > > special-purpose library-specific tweaks like this -- either the stuff > > should find its way into lib/Makefile.*, or be yanked out. > > Well, I think seperate objdirs following the source layout is cleaner > and IMO it scales better than the "few hundred files in one flat > dir"-solution (e.g. 10 dirs with 10 subdirs containing 10 subdirs > containing 10 files each is AFAIK faster to access&&handle than all > files in one flat dir (however the filename cache will hide some of the > performance bottlenecks)). As I said I had a patch for libc (AFAIK > B37-based) and could write one to do the same tree-wide to get some > things cleaned-up - if such a change is Ok... I think such a change is fine as long as it's done in a uniform manner. What we want to avoid is "Makefile fiefdoms" where things are done differently, for all of the reasons we've discussed in the past. The patch looks good. -- meem _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
