Richard Lowe writes: > James Carlson <james.d.carlson at sun.com> writes: > > As for the *.flg files, I might have to retract that comment for now. > > The xref (cscope) tools use those *.flg files and make assumptions > > about Teamware. Oh well. :-< > > The flg files are used in general, hence the changes to make flg.flp > understand mercurial. That puzzled me somewhat too, but I don't see a > better alternative to pull sundry other pieces into tags files or the > like.
Most of the value is gone, though. They were originally a Teamware artifact that allowed you to pull down just the portions of the source tree that you were interested in -- they made sure you got all of the relevant bits, even if those bits (such as header files) were in some other location. Now that we're using Mercurial, and it doesn't care as much about subtrees as did Teamware, I suspect these ought to be ditched eventually. At best, they're going to fall into disrepair over time. (Even more so than the Teamware ones did ...) > >> > usr/src/tools/onbld/Checks/Cddl.py > >> > > >> > 87: I'm no Python expert, but what does this 'else' pair with? It > >> > looks like it pairs with the 'for' at line 71, but that doesn't make > >> > sense to me. What does 'for ... else' mean? > >> > I would have expected 'if in_cddl:' as a test to perform outside of > >> > the for loop. > > > > That's the part that still puzzles me. > > We walk the entire file, line-by-line, looking for blocks. I'm not > sure how we could move that check outside the loop, given whether or > not we're expecting to be within a block varies. > > (am I not looking at the right code?) Maybe not. I was expecting an "if in_cddl" *AFTER* the loop that walks the lines in the file. If you still think you're inside the CDDL block after the line-walking loop is done, then the CDDL block is lacking an end statement. That doesn't seem to be here. Or if it is, I don't quite understand the logic used. > >> > usr/src/tools/onbld/Checks/DbLookups.py > >> > 234: this is missing onSWAN support. It should be looking at either > >> > at the NFS-mounted file /shared/sac/<ARCNAME>/<YEAR>/<CASE>/IAM.*, > >> > or at 'http://sac.eng/arc/' followed by the usual <ARCNAME> and > >> > such. > >> > >> That's intentional. We only support separate SWAN and not SWAN paths > >> where results may differ. In this case, results should never differ, > >> so the SWAN path is useless. > > > > There are both open and closed ARC cases, aren't there? > > This is... thorny, I thought the current behaviour was generally > known, but when it's been mentioned to others they've been surprised > (and in some cases unhappy). > > Some ARC cases are exposed and some are not, however, the case number > and title of *every* case is exposed. The exposure flag toggles > whether the actual materials are visible. So in the case of ARC (as > opposed to pretty much all the others), we actually have enough > information on opensolaris.org alone. Oh, ok, I get it now. I guess I was thinking in terms of full references, and not just the comment checks this supports. Your answer makes sense. > >> > usr/src/tools/onbld/Checks/Keywords.py > > Sure. I'm worried about code going forward from now. Once the gate > > is all Mercurial, I shouldn't have to worry about putting something > > like the above back. Today, I have to do this sort of subterfuge: > > > > printf("foo %X" "%s", hexval, "\n"); > > > > Being able to get rid of that nonsense seems like a benefit to me, and > > it'd be nice if the tools didn't have an SCCS hangover. > > The hangover exists so existing uses of keywords can be called out and > removed. It should be short lived. > > Is there an alternative that means it isn't needed at all? We could > look for #pragma ident, but that won't call out uses in other places, > not all of which we intend to remove during migration (do we?). > > If there's a way to avoid this, I'd like to. Anyone adding such things by way of "hg push" probably gets what he deserves. ;-} Perhaps the right answer is to file an RFE for after the transition, so that we remember (or someone else remembers) to lift this odd restriction later. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
