>> 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.
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.
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.
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.
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.
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. 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.
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.
--Mark
