[Fwd: [ksh93-integration-discuss] ksh93-integration pre-reviewround"two" (webrev 2007-05-14)]

[Peter Memishian]

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