[ksh93-integration-discuss] final ksh93 integration code review

[Peter Memishian]

 > Fixed (the flag is called "LIBSHELLCPPFLAGS").

Sounds good.

 > > I think it's
 > > the best compromise; I certainly prefer it to manually keeping the two
 > > lists in-sync.
 > 
 > Mhhh... yes... but now we have library-specific (e.g. libshell) flags in
 > a "global" Makefile include (e.g. usr/src/Makefile.ast) ... ;-(

... whereas before we just had them buried in a cmd's Makefile ;-)

 > >  > Ok...
 > >  > ... what about adding a RELEASE_BUILDNUMBER to reflect the Nevada build
 > >  > version (e.g. B61), too ?
 > > 
 > > I think that's problematic.  First, someone (or something) would have to
 > > do an integration to update it every build.
 > 
 > It seems someone is already doing that anyway:
 > -- snip --
 > $ uname -v
 > snv_61
 > -- snip --

That's not checked into the tree; I think that comes from the build
environment itself.

 > It is only "nightly" itself or are there any other scripts which depend
 > on "RELEASE", too ?

A number of things under usr/src/tools are aware of RELEASE -- and
probably a lot of other stuff that's been built over the years.

 > Is there any rule against global, single-word Makefile variables with
 > less then four letters in the Makefile style guide yet ?

No :-)

 > > How about just removing this workaround right before putback?
 > 
 > I just removed it and added a general "catch all errors and ignore
 > them"-flag called "ON_KSH_TEST_IGNORE_TESTFAILURE". Not really nice but
 > may be usefull to see all the test failures on demand (currently the
 > test run aborts on the first test failure and you have to fix them
 > sequentially...) ...
 > ... does that count as "fixed" ?

Yes, thanks.

 > +# common CPP flags for libshell consumers (ksh, shcomp etc.)

I thought shcomp wasn't part of this putback?

-- 
meem