Peter Memishian wrote:
>
> > Let's ignore the ATT Makefiles for a while. Are there other files
> > you'd like to see removed? A list based on Roland's annotated list
> > would be nice.
>
> Eliminating the ones that he called out as Documentation or tests, and
> reordering/compressing things a bit for clarity:
>
> > > > ./lib/libshell/sparc/src/cmd/ksh93/FEATURE/acct
> > > > ./lib/libdll/sparc/src/lib/libdll/FEATURE/dll
> > > > ./lib/libast/sparc/src/lib/libast/FEATURE/*
> > > > ./lib/libast/sparc/src/lib/libast/ast.req
> > > > ./lib/libast/sparc/src/lib/libast/conf
> > > > ./lib/libast/sparc/src/lib/libast/conflim.h
> >
> > 32bit SPARC platform files.
>
> If this response means that they *are* referenced on a SPARC build, then
> these are irrelevant to the discussion.
Yes... they are referenced during a SPARC (32bit+64bit) build.
[snip]
> > > > ./lib/libast/common/features/*
> > > > ./lib/libcmd/common/features/*
> > > > ./lib/libdll/common/features/*
> > > > ./lib/libshell/common/features/*
> >
> > These are feature probes (e.g. for "iffe"&co.), they're used to generate
> > the matching platform-specific files. IMO they're usefull to keep to
> > have a reference how a matching setting was selected and how they are
> > intended to be used (and you can use the probes to regenerate the files
> > on demand for testing).
>
> OK.
Ok == "keep them" ?
> > > > ./cmd/ast/msgcc/Mamfile
> > > > ./lib/libast/common/Mamfile
> > > > ./lib/libcmd/common/Mamfile
> > > > ./lib/libdll/common/Mamfile
> > > > ./lib/libpp/common/Mamfile
> > > > ./lib/libshell/common/mamexec
>
> These seem like more alien build logic (though not as likely to cause
> confusion as the alien Makefiles). Probably need to meet the same
> fate as the Makefiles.
Ok... ;-(
> > > > ./lib/libast/common/misc/magic.tab
> > > > ./lib/libast/common/port/astmath.c
> > > > ./lib/libast/common/port/atmain.C
> > > > ./lib/libast/common/port/lc.tab
> > > > ./lib/libast/common/port/lcgen.c
> > > > ./lib/libast/common/regex/regdecomp.c
> > > > ./lib/libast/common/uwin/mini.sym
> >
> > Misc. sources (some of them unused - for now).
> >
> > > > ./lib/libpp/common/ppsym.c
> > > > ./lib/libshell/common/bltins/shopen.c
> > > > ./lib/libshell/common/sh/env.c
> >
> > Unused source (for now).
> >
> > > > ./lib/libshell/common/include/env.h
> >
> > Unused header.
> >
> > > > ./lib/libast/common/dir/dirstd.h
> >
> > Unused source file (not used on this platform).
>
> More information is needed on the above. Is "for now" unbounded, or is
> there follow-on work that will make use of this stuff? For the ones not
> listed as "for now", will they ever have relevance to Solaris?
These files _may_ be used in future work. The problem is that I cannot
predict the future evolution of consumers and therefore don't know
whether they will be used or not (that's our little "Schroedingers
Cat"-problem right now with all the "currently maybe unused files").
> > > > ./lib/libast/common/astsa/align.h
> > > > ./lib/libast/common/astsa/ast.h
> > > > ./lib/libast/common/astsa/astwinsize.c
> > > > ./lib/libast/common/astsa/ccode.h
> > > > ./lib/libast/common/astsa/lclib.h
> > > > ./lib/libast/common/astsa/sig.h
> > > > ./lib/libast/common/astsa/strmatch.c
> > > > ./lib/libast/common/astsa/times.h
> >
> > Standalone AST subset glue (see usr/src/lib/libast/common/astsa/README)
>
> I'm unclear why the standalone AST environment is relevant to ON (but I
> haven't had time to read the README, so maybe that explains it).
AFAIK technicially these files could be removed.
> > > > ./lib/libast/common/comp/conf.sh
> > > > ./lib/libast/common/comp/conf.tab
> >
> > Config tab generation.
>
> Need more information.
This is like the "iffe" probed above - a static table with values and a
script to generate a couple of sources from this information, e.g.
usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conftab.c,
usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conftab.h and
usr/src/lib/libast/(${MACH}|${MACH64})/src/lib/libast/conflim.h are
created by this script based on the table information and local probing.
> > > > ./lib/libpp/common/gentab.sh
> > > > ./lib/libpp/common/pp.def
> > > > ./lib/libpp/common/pp.key
> > > > ./lib/libpp/common/pp.probe
> > > > ./lib/libpp/common/pp.tab
> >
> > Misc. feature probes and generation scripts
>
> Need more information.
See above (the same as "math.tab" and "conf.tab") - a script
("gentab.sh") is used to create sources from the matching table
information+local environment.
> > > > ./lib/libpp/common/probe.win32
> >
> > Shell script for Win32 (we discused that already)
>
> Yep, this should go.
Ok...
> > > > ./lib/libpp/sparc/gentab
> > > > ./lib/libpp/sparc/pp.req
> > > > ./lib/libpp/sparc/pp.yacc
> > > > ./lib/libpp/sparc/ppkey.yacc
> > > > ./lib/libpp/sparc/probe
> > > > ./lib/libpp/sparc/probe.sh
> >
> > Table/parser generation files etc. (not used in the OS/Net build since
> > we generated the destination files outside the tree and imported them
> > later).
>
> So what is the benefit of keeping them?
The benefit would be that we only modify the original sources (e.g.
table data) and refresh the generated sources during development (same
procedure as "math.tab" etc.).
> > > > ./lib/libshell/common/bltins/mkservice.c
> >
> > "mkservice" builtin (not used yet (it'll be enabled later as it can be
> > used to implement server-based services))
>
> Seems reasonable to keep this then.
Ok...
> > > > ./lib/libshell/common/sh/shcomp.c
> >
> > Frontend source for "shcomp" (the shell script compiler). Unused for now
> > since we forwarded this to a later case (since that case will include a
> > matching kernel module to recognize compiled shell script code).
>
> Likewise.
Ok...
> > > > ./lib/libshell/common/sh/suid_exec.c
> >
> > "suid_exec" helper for "setid" binaries (unsed - see set[ug]id script
> > discssion here and in shell-discuss at opensolaris.org).
>
> Likewise.
Even if "suid_exec.c" is not used in OS/Net (_maybe_ (currently the
exact status is not known - the old dtksh ships /usr/dt/bin/suid_exec
... either this is a mistake, a problem with Solaris dtksh (which is
based on an ancient ksh93 version 'd' alpha) or something else) we do
not need it as Casper pointed out) ?
Note that there is (small) obstacle... if we remove this file and add
something like DTrace support which requires to patch this file for
non-Solaris platforms with DTrace support we have to resurrect this file
for development (this is another reason why I am not really happy with
doing a fine-grained stripping of the codebase - in the worst case we
run into lets "remove and resurrect files"-game (which can result in
really "funny" issues when the files are deleted before they are under
SCCS control since there is then no way to figure out that such a file
exists somewhere in the project's timeline)).
> > > > ./lib/libshell/common/data/bash_pre_rc.sh
> > > > ./lib/libshell/common/data/math.tab
> >
> > Table of math functions and their attributes (e.g. number of arguments)
> > which are available by default (e.g. all the (C99) math functions are
> > controlled by this file).
>
> So at what point in the port was math.tab used?
"math.tab" is used by usr/src/lib/libshell/common/features/math.sh to
create
usr/src/lib/libshell/(${MACH}|${MACH64})/src/cmd/ksh93/FEATURE/math
(this needs to be platform-specific). We just treat it like all the
other generate files (e.g. iffe probes etc.) and import it in one step
from a native AST/ksh build (saves time and headaches to specially treat
single files).
> > > > ./lib/libshell/common/mamstate.c
> > > > ./lib/libshell/common/sh/bash.c
> >
> > Used for "bash" compatibilty mode (unused).
>
> Seems odd that mamstate.c would have something to do with bash
> compatibility mode.
Erm, no. My fault ("./lib/libshell/common/data/bash_pre_rc.sh" is a
mistake, too). ./lib/libshell/common/data/bash_pre_rc.sh and
./lib/libshell/common/sh/bash.c are for the bash emulation mode,
./lib/libshell/common/mamstate.c is the old mamfile tool ("make abstract
machine file state support").
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
