> > > > > > > http://cr.grommit.com/~chin/ksh93-webrev-jun29/jun29-makefiles/
>
> > As per your follow-up mail, I know you went ahead with this -- but did you
> > also do the KSHCPPFLAGS bit?
>
> No... I didn't like the idea much because it creates another Makefile
> include for one flag and two consumers...
>
> > That part's especially important to me
> > because without it we may have drift between the two definitions, and I
> > don't see the particular need to wait for "shcomp".
>
> Grumpf... ;-(
> ... what about adding a usr/src/Makefile.libshell (usr/src/Makefile.ast
> is IMO too generic and the flags are for libshell consumers, not ksh
> consumers (Ok... nitpicking... :-) )) ?
I was expecting you'd use the existing usr/src/Makefile.ast. I think it's
the best compromise; I certainly prefer it to manually keeping the two
lists in-sync.
> > > > > > lib/libdll/{sparc,sparcv9,amd64,i386}/Makefile:
> >
> > Anyway, like I said before, if you want to delay splitting apart RELEASE
> > into RELEASE_MAJOR and RELEASE_MINOR, I'm OK with that. But a bug should
> > be filed on the issue so that we can clean up the ksh93 Makefiles and
> > other victims of the current Makefile.master logic in the future.
>
> 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. Second (and more
importantly), we don't want software depending on the build number (it's
bad enough some software depends in the major/minor numbers).
> And what about adding an "ON_"-prefix (e.g. "ON_RELEASE_MAJOR",
> "ON_RELEASE_MINOR", "ON_RELEASE", "ON_RELEASE_BUILDNUMBER",
> "ON_VERSION", e.g. add a "namespace" called "ON_" for such tree-global
> flags ?
Sounds reasonable for new variables, but RELEASE is pretty well-known --
e.g., nightly(1) environment scripts commonly make use of it. I agree
that the generic names problematic.
> Grumpf... problem is that when I run the test suite over all locales
> then the test run will abort at the first locale iteration (note that
> the test suite is called for each of the locales defined in
> ON_KSH_TEST_LOCALES to make sure we catch any multibyte locale bugs
> (since I want to cleanup once and for all with all the xxx@@@!!!
> multibyte bugs in Solaris)) ... and there is no (easy) way to make the
> list of exceptions variable (well, wrong shell (or better: Too old...
> the idea would be to put the exceptions into an associative array and
> let the script later check whether there is an entry with that name...))
> ...
> ... what about adding an env/Makefile variable
> "ON_KSH_TEST_GETCONF_ERRATA_6548104" which is set to "0" by default
> (meaning "off") in the Makefile which can be set to "1" (=on) on demand
> from the calling shell environment (e.g. for build machines < B64) ?
Yuck. Please, no workarounds in the gate for bugs that were fixed before
the functionality needing the workaround was introduced.
How about just removing this workaround right before putback?
> > One final tiny request: would you be willing to rename Makefile.astinclude
> > to Makefile.ast or Makefile.astlib? My concern is that the name is
> > several characters wider than anything else in usr/src/lib and makes it
> > harder to see the full set of files that are in the directory with ls(1).
> > (And AFIACT the "include" part is not particularly meaningful.)
>
> Erm, "Makefile.astinclude" is exclusively for processing the AST include
> files and the filename should reflect that... mhhhh...
> ... I don't like the idea of renaming it to "Makefile.ast" because there
> is already usr/src/Makefile.ast as "generic AST flag collection Makefile
> include" while "Makefile.astinclude" specifically does library header
> processing...
> ... what about renaming it to "Makefile.asthdr" ("AST HeaDeR processing
> makefile include" ... or "Makefile.astinc" ...) ? That would be exactly
> as long as "Makefile.astmsg" ...
Ah, I'd misunderstood. Yes, "Makefile.asthdr" seems good.
--
meem
