Mark J. Nelson writes:
> Thanks tons to you and Bill for being around so late on a Friday evening.
>
> (Others, too, but I felt like I was being a bit demanding of you two in
> particular today.)
Not a problem. I was somewhat lucky today in that area -- no softball
or baseball games scheduled.
Mark J. Nelson writes:
> I think I really fouled something up in my workspace state for those
> builds, and the only thing I can think of is that I had an interrupted
> build in a workspace that I cloned using tar.
Yikes ... ok.
> I think what I'm willing to promise (jbeck and dmarker) is to no
>> I think I really fouled something up in my workspace state for those
>> builds, and the only thing I can think of is that I had an interrupted
>> build in a workspace that I cloned using tar.
>
> Yikes ... ok.
Yeah, exactly contrary to your "don't pollute the main workspace"
philosophy below.
Mark J. Nelson writes:
> > 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.
Yep.
> The
> It still feels like there's something that's not quite baked with the
> ON tools. If there are things here that need to be built as part of a
> nightly run, then perhaps they need to be on a separate target. Using
> the 'install' hammer just doesn't look right, and leads to some
> problems (se
>> 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 i
> Has anyone tried running the tools on OpenSolaris?
No. That's not this project.
> On Nevada, ksh88 is the default, and on OpenSolaris
> ksh93 is the default.
>
> For example, these scripts may have issues (we have
> other ksh scripts too)
>
> usr/src/tools/scripts/bldenv.sh
> 1 #!/usr/bin/ksh
Mark J. Nelson wrote:
>>> http://cr.opensolaris.org/~mjnelson/webrev.512.528/
>>>
Has anyone tried running the tools on OpenSolaris?
On Nevada, ksh88 is the default, and on OpenSolaris
ksh93 is the default.
For example, these scripts may have issues (we have
other ksh scripts too)
usr/src/tools
>> 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.
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 f
Duh, this note should have included these diffs, too:
14:30 fiveten [~] {1:0}% ssh elpaso.eng diff -u
/ws/onnv-gate/usr/src/tools/findunref/findunref.c
/home/mjnelson/work/scm/scm-fixes/usr/src/tools/findunref/findunref.c
--- /ws/onnv-gate/usr/src/tools/findunref/findunref.c Sat Jun 11
14:42
Mark J. Nelson writes:
> I'll need to consult with the core team (ie John, since he's explicitly
> reading this thread), but here's my opinion: Don't make exceptions for
> 'em. Let 'em be unreferenced.
+1
--
James Carlson, Solaris Networking
Sun Microsystems / 35 Network Drive
> Mark> Looks like I'm going to need another exception_list, for build
> Mark> products that aren't properly clobbered.
> Are they not properly clobbered because of makefile bugs (see 6414855)
> or because they're not supposed to be clobbered? (Though the latter
> seems like a contradiction in t
Looks like I'm going to need another exception_list, for build products
that aren't properly clobbered.
That, or we make findunref manifest-aware, or post process its output
against the manifest.
--Mark
Thanks, John. I'm going through the diffs systematically to see where I
dropped/screwed up exception list entries.
At least I assume that's what happened, and it's (hopefully obviously) to
be resolved prior to integrating this wad.
--Mark, trying to run the review of the infrastructural bits
> "Mark" == Mark J Nelson writes:
Mark> Looks like I'm going to need another exception_list, for build
Mark> products that aren't properly clobbered.
Are they not properly clobbered because of makefile bugs (see 6414855)
or because they're not supposed to be clobbered? (Though the latter
se
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
Some caveats:
- If you don't invoke nightly in a way that nightly.sh understands, it
can't always find the which_scm b
Mark> ... I believe that the diffs need to
Mark> be addressed via the exception_list files, and that I have mucked up
Mark> their content during my backout/merge/changes/recommit. So please leave
Mark> off analysing these carefully until you hear from me that I've adjusted
Mark> 'em (or tell me wh
18 matches
Mail list logo
