Thanks for all the comments!
Mark J. Nelson wrote:
> > By default, the same proto area is used for both debug and non-debug
> > builds. In some circumstances, ##nightly## will give the non-debug
> > build its proto area, which can cause problems if the user has
>
> Missing word: "its own proto area"
Right.
> 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.
> > === Incremental Build ===
> >
> > * clobber build (default)
> > * incremental build (-i)
> >
> > By default, ##nightly## cleans out the workspace before pulling from its
> > parent or starting the "make install". This cleanup include "make
>
> s/include/includes/
Right.
> > 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.
> > === 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. :-)
> > 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.
> > === 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.
> If you are introducing new nightly options, make sure that their default
> settings are appropriate for non-OS/Net builds.
>
> If you are deprecating nightly options, make sure that folks outside of
> OS/Net are not still using them.
Ah, very good points.
> 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.
> Are the nightly hooks capabilities sufficiently documented elsewhere?
There's some documentation in the nightly(1) man page. It looks okay to
me, but I've never really tried to use the hooks, so I wouldn't be
surprised if I'm missing something.
mike
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
