Peter Memishian wrote: > > > 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.
Erm, it isn't my intention to "prevent" people from doing that put patches should be submitted to upstream and then pulled-in with the next update (currently planned in updates every three months). I really don't want to end-up with the mess from which the old Solaris ksh is suffering from. [snip] > > 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. Fixed. > > 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.) "lint" seems to work without problems - a quick look in the build log shows the following line: -- snip -- /opt/SUNWspro/bin/lint -uaxm -DTEXT_DOMAIN=\"SUNW_OST_OSLIB\" -D_TS_ERRNO '-DHOSTTYPE="sol11.i386"' -I. -I/home/test001/ksh93/on_build1/test1_x86/proto/root_i386/usr/include/ast '-DCONF_LIBSUFFIX=".so"' '-DCONF_LIBPREFIX="lib"' -D_BLD_dll -D_PACKAGE_ast -D_BLD_DLL -errtags=yes -s -erroff=E_PTRDIFF_OVERFLOW -erroff=E_ASSIGN_NARROW_CONV -U__PRAGMA_REDEFINE_EXTNAME -Xc99=%all -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -errsecurity=core -erroff=E_SEC_CREAT_WITHOUT_EXCL -erroff=E_SEC_FORBIDDEN_WARN_CREAT -erroff=E_ASSIGN_INT_TO_SMALL_INT -erroff=E_CAST_INT_CONST_TO_SMALL_INT -erroff=E_CAST_INT_TO_SMALL_INT -erroff=E_CAST_TO_PTR_FROM_INT -erroff=E_COMP_INT_WITH_LARGE_INT -erroff=E_INTEGRAL_CONST_EXP_EXPECTED -erroff=E_PASS_INT_TO_SMALL_INT -erroff=E_PTR_CONV_LOSES_BITS -o dll ../common/llib-ldll > lint.out 2>&1 -- snip -- "-Xc99=%all -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1" is correctly passed to "lint" in this case... What should I do in this case ? Keep the current design or find another solution ? > > > 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. Well, it's done uniformly for all AST libraries which use subdirs in the sources (e.g. libdll is an exception because it is too small to have subdirs in the sources). ---- Bye, Roland P.S.: Updated patch gets attached to the next email... -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
