> X-Authentication-Warning: dhcp-cbjs05-219-32.PRC.Sun.COM: meem set sender to
peter.memishian at sun.com using -f
> From: Peter Memishian <peter.memishian at sun.com>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Tue, 27 Feb 2007 00:34:40 +0800
> To: Roland Mainz <roland.mainz at nrubsig.org>
> Cc: Peter.Memishian at sun.com, David.Comay at sun.com,
> ksh93-integration-discuss
<ksh93-integration-discuss at opensolaris.org>, OpenSolaris Code mailing list
<opensolaris-code at opensolaris.org>, Mike Kupfer <mike.kupfer at sun.com>,
April
Chin <April.Chin at eng.sun.com>
> Subject: Re: [osol-code] Round
two:((pre-)pre-review)ksh93-integrationwebrev2007-02-02
>
>
> > > First, documentation is generally not subject to the same sort of rules.
> > > You'll note that findunref already contains a blanket exception for text
> > > files and READMEs. Second, if the source file can reasonably be argued
to
> > > have value on Solaris, then it's fine. However, a directory filled with
> > > (e.g.) Windows NT specific files would be hard to argue for.
> >
> > The only windows files in the tree are
> > 1. usr/src/lib/libpp/common/probe.win32
> > 2. include/ast_windows.h
> >
> > [1} can likely go away but [2] is an include file which is referenced
> > even on Unix/Linux and therefore we can't remove it easily.
>
> [1] needs to die. If [2] is referenced, it's not part of this discussion.
>
> > > As I mentioned in an earlier email, we generally grant exceptions for
> > > parts of the source tree that are kept in-sync with an upstream source.
> > > But the exception should not be used to stockpile support for non-Solaris
> > > platforms provided that the files could be automatically pruned from the
> > > upstream source without too much effort.
> >
> > See above... AFAIK that are the only files which could be removed.
>
> You can verify this is the case by putting "f" in your NIGHTLY_OPTIONS and
> examining usr/src/unref-`uname -p`.out once the build finishes. Note that
> you will see a bunch of existing unreferenced files in the list, since the
> policy against unreferenced files is only goes back 5 years and was not
> retroactively enforced. (Also, to get a completely accurate list, you'll
> need to build on both SPARC and x86 and then merge the resulting files.)
Thanks for these pointers.
Full nightly builds (sparc & x86) on Roland's workspace (version 619)
using the -f option yielded no new unreferenced files...the
usr/src/unref-{sparc,i386}.out files are identical to the
usr/src/unref-{sparc,i386}.ref files.
April
>
> --
> meem
