> 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.
OK, we're on the same page. >>> 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. Point well taken. Satisfying dmarker is necessary, but not sufficient. Not worth rocking this boat outside of the context of fixing more general tools issues. >>> 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. :-/ 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. I think what I'm willing to promise (jbeck and dmarker) is to not pollute their findunref output with our putback. As long as we don't care about successive sparc and i386 clobber builds for findunref in the same workspace (who would DO such an icky thing?) we're pretty much there. > % ws /path/to/ws > % cd $SRC/tools > % dmake install > > Right? Nope. It will just not include the scm-specific exception list entries. But the tools that are built will be the same. >> 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. I did fix both the nightly.sh and bldenv.sh scripts to get which_scm from $(dirname $(whence $0)), and to fallback to $PATH (by way of invoking which_scm with no leading path) if that file fails a -x test. Tested bldenv unmodified on teamware and mercurial workspaces, hacked nightly to make sure it found the right thing. Will push soon. --Mark
