>> Unrelated to your writeup: Any idea why we don't make MULTI_PROTO the
>> default?
>
> At the time, Danek was concerned about the additional storage that would
> be consumed.
Might still be a valid concern on public build machines.
>>> It is okay for your changes to introduce warnings for an incremental
>>> build, but the build must still be able to complete. If you do
>>> introduce warnings, you should send a heads-up email after your
>>> putback to tell gatelings not to worry about the warnings. This
>>> typically happens when you have deleted or moved installed files,
>>> which causes the packaging step of the build of complain that it
>>> doesn't know how to package the old files.
>>
>> The last paragraph seems mostly unrelated to making changes to
>> nightly.sh?
>
> I'd be happy to delete the last sentence. The rest of the paragraph
> seems relevant to me.
I guess I'm not imagining changes to nightly.sh that result in
incremental build failures.
>>> === Old/new Nightly ===
>>>
>>> * new nightly, new source
>>> * new nightly, old source
>>> * old nightly, new source
>>>
>>> Many developers run ##nightly## from /ws/onnv-tools/onbld/bin, which is
>>> updated daily. In general, your new version of ##nightly## should be
>>> able to build workspaces that haven't yet merged in your changes.
>>> Note that a workspace might contain old source for the clobber phase
>>> and then contain your changes for the "make install" phase. (See also
>>> the section on "updates" below.)
>>
>> The warning about old clobber / new install bits seems unrelated to
>> which version of nightly.sh you're using?
>
> Well, the point of the warning was not to assume that you're building an
> "old" workspace or a "new" workspace, because the old/new status can
> (but need not) change as a result of the pull. I'm open to other
> wording. :-)
I'm not sure it's worth the emphasis. The clobber portion of nightly.sh
makes no such assumptions, and the build portion should continue to work
with either. But it might be confusing to gloss over it, so maybe
something like:
* old nightly, old source: This is assumed to work.
* old nightly, new source: If this does not work, you will need to send
a flag day note, preferably with an example of the failure mode.
* new nightly, old source: You should make this work if it's reasonable
to do so. Otherwise, you will need to send a flag day note, preferably
with an example of the failure mode.
* new nightly, new source: This is assumed to work.
Note that there is a special transition case, in which nightly is used
to automatically pull your changes. In this case, the "make clobber"
will be done with old source, but the "make install" will be done with
new source. This leads to the following additional cases:
* old nightly, transition: As with old nightly, new source above.
* new nightly, transition: As with new nightly, old source above.
>>> As mentioned above ("old/new nightly"), the user's repo might not
>>> contain your changes prior to the update. Make sure you handle that
>>> transition case okay.
>>
>> s/okay\./okay, or send a flag day note warning users to manually update
>> their workspaces./
>
> Okay.
Or this goes away with above verbiage.
>>> === closed tree ===
> [...]
>> This section is also related to the Consolidation section. If you make
>> changes around how nightly behaves with regard to the closed tree, you
>> should also make sure that your defaults are sane for consolidations
>> that have no closed tree.
>
> Okay, I'll look at beefing up the wording here.
>
>> Also potentially missing a section on Tools here. If you're mucking
>> with nightly's PATH manipulations, be aware that non-OS/Net
>> consolidations rely on the -t behavior to build their tools, even though
>> the subsequent PATH updates are benign (since they won't have an
>> opt/onbld in their tools proto area).
>
> Hmm. I'll look at this and think about what to say.
Might not be necessary, but I screwed it up at least once.
>> It expands the scope of your writeup, so I understand if you don't want
>> to do so, but it would likely be useful to annotate or outline the
>> nightly script, and to provide some explicit how-to notes. For example,
>> when to use $ROOT vs $checkroot. Or naming/suffix conventions for open
>> vs closed and DEBUG vs non-DEBUG builds.
>
> Yeah, that sounds like a good follow-on project. Though it might be
> better in some cases to restructure the code for clarity, rather than
> just documenting its many dark corners.
Surely you're not suggesting that nightly lacks clarity.
--Mark
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
