Mark J. Nelson writes:
> 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?
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.
(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.)
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. :-<)
usr/src/tools/scripts/nightly.sh
2928: why not "!="?
> - 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.
Of course, building on a newer build machine is even better. ;-}
> - 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.
> 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?)
--
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
