> > * A number of places do something like this: > > > > # > > # ksh is not lint-clean yet. Fake up a target. > > # > > lint: > > @ print "usr/src/cmd/ksh is not lint-clean: skipping" > > @ $(TRUE) > > > > The above doesn't seem consistent with the way we handle this > > elsewhere in ON. Instead, the general rule is to have a normal > > lint target that spews warnings, and simply omit the directory > > from $(SRC)/Makefile.lint > > AFAIK (if I remeber this correctly) we tried that and it didn't work and > then we've copied the solution of the "perl" built - see > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/perl/Makefile#59 > The original "Incomplete Tourist Guide" covered this item - see > http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2006-June/000433.html
It mentions it, but I don't see a justification. We generally only use that for things we know we will never make lint-clean -- and there are only two examples of that which I see in ON (fmli and perl). Everything else works the way I suggested. > > > * A number of places use "COBJS" rather than "OBJECTS" directly -- > > > > Unless there's some problem with OBJECTS, it should be used > > directly. That way, macros like SRCS will work automatically. > > Erm, I've copied that from other Makefiles which used COBJS. It seems > both styles are used within OS/Net - which one is the preferred ? usr/src/lib/README.Makefiles recommends OBJECTS and never suggests COBJS. > > * A number of places have stuff like: > > > > # mapfile-vers does not live in common/ because this directory > > # is for AST code only > > MAPFILES= ../mapfile-vers > > MAPOPTS= $(MAPFILES:%=-M %) > > DYNFLAGS += $(MAPOPTS) > > > > It's not clear to me why common/ is "for AST code only" > > This was done to simplify updates (e.g. to avoid that an semi-automated > update prodecure doesn't crush other sources to death). But the trade-off is that it's different from almost every other library Makefile. But if you really believe it simpifies updates, I'm OK with it -- just make that clear in the comment (and remove the MAPOPTS and DYNFLAGS stuff). > > * A number of places have stuff like: > > > > # Override this top level flag so the compiler builds in its > > # native C99 mode. This has been enabled to support the math > > # stuff in ksh93. > > C99MODE= $(C99_ENABLE) -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 > > > > I'm not sure what the two -D directives have to do with enabling > > C99 mode, though. > > We compile ksh93 as C99/XPG6 application for a number of reasons, I'm not objecting to that. I'm pointing out that C99MODE is being abused to enable XPG6 as well. Why aren't those #defines in CPPFLAGS? > > * I don't really understand what the "confusion with having too > > many object files in the toplevel pics/ directory" is. > > It's my desire to avoid having hundreds of object files in one subdir > when it is possible to put the object files into subdirs which follow > the subdir layout of the source code (e.g. see Mozilla codebase for > another example). IMO it's cleaner and easier to navigate (at least for > humans) with subdirs than using the DOS1.0-style and dump all objects > into one flat directory (I have a similar patch for libc which should > solve the madness in those Makefiles, too...). 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. In general, anything that makes a library Makefile different from the norm introduces maintenance overhead and thus needs to be carefully considered. -- meem _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
