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 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.
Ah, ok. This came in somewhat recently (snv_68) when I wasn't
looking. ;-}
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 (see below).
> > 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.
Indeed. That's why it's strange to me.
> > (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.
OK. It just makes the whole "why are we doing 'make install' on the
tools directory again?" question more visible. That's all.
> > 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.
OK; thanks.
> > 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.
OK, I see it now. (Below)
> > 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.
OK ... but note that you'll also cause a big unref blip for all of the
gatelings as well (at least the anal ones like me who do "-f" all the
time). I'm not sure that's the path of least resistance.
> > 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.
OK ... though I saw a lot of sparc-looking things there. :-/
Mark J. Nelson writes:
> >> 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.
>
> I'm not convinced.
About /usr/ucb and /usr/etc? ;-}
> I know that I earlier complained about being bitten by nightly.sh being
> unable to find which_scm. But I think that's an issue with nightly.sh.
> It tries to use which_scm before it does use_tools(). I don't know if
> that's avoidable, and we should figure that out before we integrate.
Hmm. I'd thought I'd fixed this in the last pass on the problem, but
it now doesn't appear so. (I'm very confused by that, because I
checked each of the which_scm users.)
In any event, the way this is supposed to work is that we use
$(dirname $(whence $0)) as a path for which_scm, as we ought to find
which_scm in the same place we found nightly.
> But nightly.sh never uses $nightly_path to try to find any other tools,
> only to deal with nfs issues when copying proto into the parent workspace.
Agreed. That's broken. I think doing this:
WHICH_SCM=$(dirname $nightly_path)/which_scm
... and then using $WHICH_SCM in place of which_scm in wstype will fix
the problem.
> In fact, I think bldenv.sh comes closer to getting this right: the
> which_scm call comes AFTER ${PATH} is built, including appending the
> workspace-local tools proto area for -t (default) builds.
Yes.
> That would appear to be a chicken-and-egg problem, in that TOOLS_PROTO
> isn't populated yet for a clean workspace, until you do a make setup. So
> if you're doing manual builds, and you reference SCM_TYPE, then your build
> environment won't be set correctly.
I don't agree. The which_scm script should not necessarily come from
the workspace that's being built. Instead, it's a companion of
'nightly' itself, and should come from the same path that houses
'nightly'.
If we're indeed running 'nightly' right out of the workspace being
built, then that's fine, get which_scm from there. But getting one
script from one location and another from a different one seems odd
and potentially dangerous to me, if they were to be out of sync
somehow. (It's not as if the which_scm command line or output are
"stable" interfaces.)
This actually points up a long-standing problem with the tools. When
specifying "-t" (now the default, I know), it doesn't make sense to
keep running the nightly script from the build system's SUNWonbld
package. We *should* "build" nightly in the workspace, and exec
ourselves over early in the process.
> But for now, this only affects findunref, the single, lonely consumer of
> SCM_TYPE from the environment. And I assert that findunref is utterly
> uninteresting outside of the context of a full build controlled by
> nightly.sh.
Agreed. Though a "make install" in $SRC/tools now uses that variable
-- which may not actually be set.
In other words, I think this will fail in your updated workspace:
% ws /path/to/ws
% cd $SRC/tools
% dmake install
Right?
> So we're back to making sure that nightly.sh finds which_scm,
> and that's only an issue during the transition to using these tools.
>
> Fixing it by calling which_scm from the findunref Makefile is another
> option, but then findunref gets a dependency on scripts in
> usr/src/tools/Makefile.
>
> Ugh.
Part of the problem here is as mentioned above: this exclusion list
creation almost certainly shouldn't be part of the "install" target.
> I don't think we want to hack the scripts for this. I think we want to
> send a build machine flag day to install the right tools, and make sure it
> mentions the which_scm failure.
OK.
--
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
