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

[Peter Memishian]

 > * Webrev only over files which match the substring "makefile":
 > http://www.nrubsig.org/people/gisburn/work/solaris/ksh93_integration/ksh93_integration_prototype005_webrev_20070514/makefile_files/webrev/

I haven't had time to go through everything yet, but here a few general
things that caught my eye:

	* 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

	* A number of places use "COBJS" rather than "OBJECTS" directly --
	  e.g.:

 	    COBJS= \
 	         dlfcn.o \
 	         dllfind.o \
 	         dlllook.o \
 	         dllnext.o \
 	         dllplug.o \
 	         dllscan.o

	   Unless there's some problem with OBJECTS, it should be used
	   directly.  That way, macros like SRCS will work automatically.
	   
	* 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" -- but
	  at worst you should need to redefine MAPFILES, not the other two.

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

	* I don't really understand what the "confusion with having too
	  many object files in the toplevel pics/ directory" is.  Please
	  explain why the special mkpcdirs handling is necessary.

--
meem