> 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
