> 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. > > > ./lib/libshell/sparcv9/src/cmd/ksh93/FEATURE/acct > > > ./lib/libdll/sparcv9/src/lib/libdll/FEATURE/dll > > > ./lib/libast/sparcv9/src/lib/libast/FEATURE/* > > > ./lib/libast/sparcv9/src/lib/libast/ast.req > > > ./lib/libast/sparcv9/src/lib/libast/conf > > > ./lib/libast/sparcv9/src/lib/libast/conflim.h > > 64bit SPARC platform files. Likewise. > > > ./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. > > > ./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. > > > ./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? > > > ./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). > > > ./lib/libast/common/comp/conf.sh > > > ./lib/libast/common/comp/conf.tab > > Config tab generation. Need more information. > > > ./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. > > > ./lib/libpp/common/probe.win32 > > Shell script for Win32 (we discused that already) Yep, this should go. > > > ./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? > > > ./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. > > > ./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. > > > ./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. > > > ./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? > > > ./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. -- meem
