>> http://cr.opensolaris.org/~mjnelson/webrev.512.528/ >> >> This covers the following: >> >> 512 exclusion list has dropped an entry >> 528 revert findunref from Python to c > > Thanks for doing 528; I think that's really the right answer, even > though there are Python fans out there. > > usr/src/tools/findunref/Makefile > > It looks like the assumption here is that findunref itself is always > rebuilt in every workspace, so that the combined exception_list is > available. Why should that be?
All roads lead to here, basically. The bldtools target in usr/src/Makefile does a make install in usr/src/tools. The setup, all, and install targets have direct or indirect dependencies on bldtools. When install is propagated to usr/src/tools/findunref, it depends on all. > In other words, I think building both findunref and exception_list > as part of the 'all' target but installing only findunref in the > 'install' target is a bit odd. The exception_list is tied intimately to a workspace, and should not be installed or packaged anywhere else. The tools themselves, on the other hand, are not. > (Fixing findunref.c so that it accepts argc >= 2 rather than just == > 2 ought to be fairly simple, so I'm a little wobbly on this change. > Though I do see how it simplifies nightly.) I went with what I considered to be the path of least resistance, and what (to me) seemed natural. I could move the complexity out of the makefile and into nightly.sh (and make findunref.c more complex in the bargain), but I'll push back a bit before doing so, because I'm not yet convinced that would be any better, really. > usr/src/tools/scripts/bldenv.sh > > 410: note that PATH was changed on line 328. I think we need to do > the same 'whence' trick here rather than hard-coding > /opt/onbld/bin to avoid transition problems. (And seeing > /usr/ucb and /usr/etc in that list just makes me ill. :-<) I'll look at the PATH/whence issue. > usr/src/tools/scripts/nightly.sh > > 2928: why not "!="? I think the line number you gave is for a preexisting instance of the same offense. :) On 2992, I did it again. "Habit," I guess, is my answer. Changing it will make it more legible. I'll do so. >> - If you don't invoke nightly in a way that nightly.sh understands, it >> can't always find the which_scm binary. That's a problem for testing >> these changes (see below), but not really for most users >> post-tools-putback. On a related note, I tested the bldenv changes, and >> they exported SCM_TYPE correctly, and a subsequent build of the >> exception_list correctly included mercurial. > > I'm not sure what you mean here, but I suspect you're doing "ksh > /path/to/nightly.sh". If so, then that won't work as expected unless > you're on a build machine that already has which_scm installed. > > For testing, I used to just run $SRC/tools/scripts/nightly or do a > full "make install" under $SRC/tools ... "building" it is pretty > simple, and it avoids this issue. I invoked it as /full/path/to/usr/src/tools/proto/opt/onbld/bin/nightly in my workspace, and it failed to find which_scm. > Of course, building on a newer build machine is even better. ;-} I was going for expedience here... >> - I got rid of the multiple invocations of findunref in nightly.sh, but I >> preserved the path munging. I think that's wrong, but the fix is (now) >> simply to remove the sed from nightly.sh. I didn't do that here, >> because I think it warrants asking the gk team about whether they mind a >> massive unref diff from the first nightly following our putback. > > Up until now, I think we've been working to keep that sort of blip > from occurring. It gives gatekeepers much less than warm-and-fuzzy > feelings about our putback -- it'll look like we might be sneaking in > some trash. I might promise dmarker to carefully vet the unrefmaster after our putback; that might satisfy him. >> 30a31,34 >>> ../closed/lib/libike/sparc/sshconf.h >>> ../closed/lib/smartcard/cardterminals/scm_ifdh/common/scm_ifdh.h >>> ../closed/lib/smartcard/cardterminals/scm_ifdh/common/scm_protocol.h >>> ../closed/uts/common/sys/adapters/marvell88sx/.del-marvell88sx.h-Jan-26-06 > > A lot of the output _appears_ to me to be from working with x86 build > output only, and not from generating an unrefmaster.out. (Is that > right?) I think it's mostly failure to clobber. These are definitely from the unrefmaster files. --Mark
