Roland Mainz writes: > 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... :-)
I think that misses the point. I wasn't talking about testing. I was talking about having others read the code as written, understand it, and then (if necessary) being able to make successful changes to it. Having the code decorated with grot required to get shell constructs to work out right in a makefile -- both the extra escaping and careful use of semicolons where newlines are ordinarily enough -- make this harder to read and thus harder to maintain. For short expanses (say, two or three lines), it's not a big deal. It becomes worse when there are dozens of lines in there and indentation is no longer your friend. > 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. That wasn't the question, but thanks. > > 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... It was meant as a joke. There's a perfectly good shell script in here, but it's been transliterated (not translated) into a form that 'make' is able to transliterate back into shell syntax. It's alien. > > > 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" Notably, it already does a big 'export' to make the LD_LIBRARY_PATH stuff work. Other than that, and ignoring the things that are already known to be defined in the build environment, I see $(CMDTRANSMACH), $(ON_KSH_TEST_LOCALES), and $(ON_KSH_TEST_LIST). Really not much, I think. > > 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). I agree those are big. However, in the context of a Makefile, I find anything over a line or two long to be "largish." > > $(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". Nothing about $(ROOTFS_LIBS), $(ROOTFS_LINKS), or $(ROOTFS_LINTLIB) seems to create anything that $(ROOTDEMODIRS) could conceivably need. If it does, then I'd very much like to understand how these things are in fact entangled. This looks quite obscure to me. Are we looking at the same code ... ? I'm looking at: http://cr.grommit.com/~chin/ksh93-webrev-jul9/jul9-nonattfiles/usr/src/cmd/sgs/libelf/Makefile.targ.sdiff.html The .WAIT I find confusing is the first one on line 54 on the right hand side. I suspect that $(ROOTDEMODIRS) should just have been added to line 53 (without an extra .WAIT). > > > - 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 OK; not needed right now. > (IMO we need a mailinglist or project to bundle the > OpenSolaris-related standard issues...)) It probably depends on the problem, but if it's a utility problem, it might be good to have a group for that. A "standards" group strikes me as a little too divorced from the code itself. (But, not my call to make.) > > > - 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| ... If the strings are path names, there's no much you can do past that limit, is there ... ? > 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)... ;-( ) I don't know the details of that one, but if it's fixable at all, it'd be nice to see more of /usr/xpg4/bin/grep show up in /usr/bin/grep -- at least to the extent that backward compatibility allows. > > 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) ? If you understand the compatibility constraints and still think that the cure for that particular problem needs disbelieving quotes, then I'm not sure how we could have a productive discussion. That's an interesting example *because* it was so hard to fix right, and though the fix is complicated, I don't think the word "hack" is quite right. I would not want to see backward compatibility broken. Period. If the work done here can't be done without breaking compatibility, and the breakage is not in trivial areas, then we've got a very big problem. However, if the new library is drop-in compatible, then I don't care nearly as much how it's constructed internally, and it's the project team's problem to figure out which is the best way to go. I wouldn't want to see the ARC involved in a question like that. > 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.). Indeed. I would expect a lot more than just a "prototype." I'd expect something like a design. > 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... I'd rather see work discarded than to see things break. It's that simple. > [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 ? I'm not sure how that's relevant. > > 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). I think you've misunderstood some of the requirements here. Cstyle doesn't magically pop into existence because you're working in libc or some other "famous" area in the tree. It's a putback requirement for all of ON. It gets specifically waived for projects *IF* there are overriding concerns, such as remaining in sync with some external source. That shouldn't be a barrier. The rest is about how the sources are compiled and whether they really are compatible with the things that are already in libc. My guess would be that they're not really compatible, because of how complex some of the multithreading features are, but I suppose I could be surprised. In any event, we're talking about a lament in my original review comments, not about something that can or should reasonably be fixed right now. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
