James Carlson wrote: > Roland Mainz writes: [snip] > > > - It'd be nice (though not required) to have helper scripts to do > > > the grunt work required during the build process. In particular, > > > $SRC/cmd/kes/Makefile.testshell is pretty hard to read, > > > > Why ? It's only one extra layer of esacping rules (for example > > Imakefiles have at least two layers) ... :-) > > It's just the "ick" factor. It's hard to read and thus hard to > maintain properly.
Well, if it doesn't work you trigger either a shell syntax error or the shtest run will not work. And the use of "set -o errexit" will catch most other "dumb" mistakes... AFAIK there is little room for errors which will result in a successfull test run... :-) BTW: If you have problems editing the code or "looking through the Makefile escaping" add an "exit 1 ; \"-line at the beginning of the script - "dmake" will return an error and the error message will show the "decoded" shell script. Or simply use "set -o xtrace" to follow what the script is currently doing. > We could also transliterate it into Korean, but that probably wouldn't > help much, either. :-> Erm... slightly offtopic... but do you mean "transliteration" or "translation" ? Right now I can't imagine how a transliteration of english text into korean should work... the reverse way (romanisation) has seveal solutions but I can't remeber any method for doing something like a reversion into korean... > > > with a > > > bunch of escapes that are complicated by the fact that it's coded > > > in the middle of a makefile. Two or three lines are ok, but 58 > > > lines seems like a lot. > > > > Erm... the problem is that it needs _lots_ of variables from the main > > Makefile > > Yes, I see that. It needs "several." Mhhh... I thought in english it's more or less like "more than five" (= one hand) ---> "lots" > > and an external script would still require access to all those > > makefiles, e.g. you won't save much by replacing the current > > "in-Makefile" script with a giant list of variables passed to a script. > > And the script has 58 lines but around ~~18 extra lines are needed to > > squish the script into the 80-column format... ;-( > > ... but: If we switch SHELL=/usr/bin/ksh over to SHELL=/usr/bin/ksh93 at > > least ~~8-12 lines can be removed (e.g. all the "egrep" usage, the > > weired "while read ; print $REPLY ..."-loop etc.) > > Still, when possible, I prefer to see largish scripts delivered > separately from the makefile. I don't think this script is "largish" ... it's just a loop which iterates through a list of locales and runs the list of tests per locale while setting-up some variables for each "shtest" call... IMO "largish" scripts are things like "bfu", "gnaw" or "shinvaders" ... but not this one (otherwise the AST header generation "scriptlet" would require a seperate script, too). [snip] > > > - $SRC/cmd/sgs/libelf/Makefile.targ: why is a .WAIT needed before > > > $(ROOTDEMODIRS)? It looks like it should go with the rest of the > > > directory targets. (Probably just a nit.) > > > > Erm... the ".WAIT" rule should make sure that the directories really > > exist before creating files into it, e.g. first create dirs, then > > populate it. > > I don't follow. > > $(ROOTDEMODIRS) is itself delivering a directory, and nothing else. > Does that directory depend on any of the directories that appear > before it in the list? I don't think that it does. > > I'm asking about the .WAIT that is *before* the $(ROOTDEMODIRS), and > not the one after. What about the base directory ? If ROOTDEMODIRS contains multiple directories which itself depend on a directory which was created before that point we get a build race without the ".WAIT". [snip] > > > is still > > > frightening. Not an issue to hold up integration, but I hope that > > > something better will be done in the future. Supporting more than > > > one libc in ON seems like a hazard. > > > > Well, there are at least four items why this part is there: > > Yes; I'm well aware. But in giving final comments, I still feel > I'd be remiss if I didn't mention that I think this kind of > duplication is a mistake, no matter what the intent. > > > - Solaris libc functions not conforming to POSIX/XPG standards (this is > > If you find any standards conformance problems, please do file bugs. Ok (this point will need some time since I have to discuss the list with Don first (IMO we need a mailinglist or project to bundle the OpenSolaris-related standard issues...)) > > - Historical limitations of the libc implementation (for example the > > Also, file bugs. Ok (but I am not sure whether it will help... some values like |PATH_MAX| cannot be changed because the functions which rely on it cannt use higher values because they may break existing applications which assume that the functions will cut-off strings at |PATH_MAX| ... and other problems like /usr/bin/grep not being CSI-enabled will likely stick around forever (or at least I am worring about this after reading the discussion and Irek's rants about "multibyte issues vs. commands in /usr/bin/" in opensolaris-discuss at opensolaris.org)... ;-( ) > > Solaris libc stdio implementation where is no way to integrate the AST > > stdio functionality without breaking backwards compatibilty (which is a > > _pain_ because the AST stdio implementation is much more flexible and > > _FASTER_). In theory there is the option to provide a build-time switch > > and build all new applications with an all-new stdio implementation... > > but I don't even dare to imagine how the matching ARC case would look > > like (war ? bloodbath ?) ...) > > Having two of them seems like the worse answer. I'd like to have one. > If moving some or all libast things into libc is the answer that > solves the duplication, then it sounds like a possible future way > forward to me. > > I don't see why you're assuming there'd be a "war" here. I don't get > it. Well, I guess the ARC cause would be "hell" (maybe I am using the wrong words in this case... I am not really used to lots of bickering... ;-( ). For example: Which stdio implentation should be used for the "new" libc one - the AST, GNU, SchillyStdio or just apply another bunch of hacks to workaround the problem (like the hack to "cure" the "256 file descriptor"-limit) ? I imagine it will require _lots_ of bickering and finally require a "written opinion" to solve the bickering. And someone has to write a prototype to check which problems may arise from replacing the old stdio implementation with something newer (this includes items like source code compatibilty, thread-safeness etc.). Writing the prototype based on libast's stdio isn't a big problem (except that it takes lost of time) ... but I don't like to see that work thrown into the trashcan because the ARC case was pushed into a completely different direction... [snip] > > happy to have "extensions" in the "XPG6 standard mode") > > We've done it in other areas. XPG _allows_ extensions. Yes... but are the standards folks _happy_ with such extensions ? > > - Someone has to maintain the code. libast is maintained by David, Glenn > > and the AST community, including further development. If we put the > > functions into Solaris libc - who would do the syncing with upstream > > and/or doing further enhancements ? > > Actually, you're putting libast into ON. Someone has to pull changes > from the AST community and get them into ON. That doesn't happen > "automatically," and it's not done by the AST people. That same > someone who updates ON can very likely deal with things if the same > files are in different locations. > > I don't see that as a substantial issue. There is a "small" difference... the current implementation of this putback is a "low maintaince" design... it doesn't change the upstream code (Ok... this has multiple reasons, not only this one...). Putting libast code into libc will require larger changes in the upstream sources and that will require lots of work (and even simple work like comparing the AST and OS/Net workspaces will require more work because the libc parts need to conform to "cstyle" which ruins any simple way (like $ /usr/bin/diff -u ... #) to check for code differences) and someone who _cares_ about the code and has enougth time to do it (e.g. it may be an impossible task for a single contributor). > > > - No changes were made to these files: > > > $SRC/lib/libcmd/amd64/Makefile > > > $SRC/lib/libcmd/i386/Makefile > > > $SRC/lib/libcmd/sparc/Makefile > > > $SRC/lib/libcmd/sparcv9/Makefile > > > Don't deliver unchanged files. > > > > What do you mean ? > > Take a look at the diffs -- there are no changes to those files. They > need to be removed from the workspace and reverted to the original in > the gate. Ok... ... fixed. > > > - $SRC/pkgdefs/Makefile: looks like a missed merge. (Not a code > > > review issue, but you'll want to clean it up before going for > > > RTI.) > > > > Erm... what do you mean ? > > Just a construction error in building the webrev. April needs to make > a new one. Ok... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
