Richard Lowe wrote:
> Roland Mainz wrote:
> > Mike Kupfer wrote:
> >>>>>>> "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes:
> >> Roland> but I fear which possible "precedent" could be constructed from
> >> Roland> that (like "... lets rename all files which are unused from ${i}
> >> Roland> to ${i}.unused ..." or something like that) ... ;-( ).
> >>
> >> Clearly marking unused files as unused makes it easier for people to
> >> come up to speed with the source. So while I concede that such a
> >> precedent would make more work for you, it's not an entirely bad thing.
> >
> > The question is (as you said earlier) where we should draw the line.
> > Somehow the discussion about the Makefiles has more or less worn out my
> > shields (e.g. renaming the Makefiles to "Makefile.att" (and remove
> > "probe.win32" to make Peter happy) _may_ be OK for me if this is
> > ___explicitly___ _not_ used as precended to strip or rename any further
> > upstream files (violations are punished by Bel-Shamharoth himself))) but
> > I still fear the precedent generated by this.
>
> I fail to see how removing source we don't (and in the case of the win32
> bits will not ever) use is a problem.
As I tried to explain it greatly disturbs the update procedure and
identifying really unused files may not be as easy as you think. Some
files are disabled for now for various reasons (like mkservice.c
("mkservice" builtin command) or shcomp.c (shell script compiler,
forwarded to a later ARC case)), are used "manually" (like regression
tests or the feature probes) or used in another context like debugging.
That's one of the reasons why I am opposed to "random" stripping (quick
check: Excluding documentation, Makefiles, Mamfiles, iffe feature probes
and usr/src/lib/libshell/common/sh/bash.c we have six really "unused"
files in the tree (where "unused" is relative since this only applies to
Solaris)).
Another reason is that this may be very risky because depending on
include order some files may be unused now but used with the next minor
source update (and detecting something like a "missing include file" may
be tricky since some sources with the same filename in different subdirs
have a different purpose - it may compile but the resulting binary will
not work (we've spend some time in that hell - and this problem was
_exactly_ the reason why we abandoned the first ksh93-integration
codebase and designed the a completely new solution (resulting in
prototype002, -003, -004))).
> Is there even documentary value to
> such a thing? Does their not being present really make updates more
> difficult? (how?)
Grumpf... I explained that earlier. Short: The patches generated from
the upstream sources will no longer apply and we would need to create a
bullet-proof way to handle "missing" files (which will not be easy
(which means: Removing files will greatly inflict pain on our side with
exactly _zero_ benefits (except that we need much more time for updates
and add more innovative ways to shoot ourselves into our feet (or short:
Reduced quality will be one of the results of "random" file stripping...
;-( )))).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
