On Fri, May 4, 2012 at 7:15 AM, Glenn Fowler <[email protected]> wrote: > > we will not be taking this patch because the next beta will have > PATH-based mechanisms for accessing builtins from plugin libraries other than > -lcmd
OK > this will allow script testers to access builtins from -lcmdtst by modifying > PATH > in a way equivalent to how script testers would access new binaries by > modifying PATH > > I mentioned this before but I'll repeat for emphasis > while we think the grep and xargs builtins are correct > they are still beta > and given that builtins have full access to all ksh resources > even an otherwise innoccuous bug not detected in the standalone grep > could wreak havoc in ksh from builtin grep > 30+ years of writing standalone apps numbs one to the amount of cruft _exit() > takes care of > and we should all be a bit skeptical since dgk and I are using experience > with -lcmdtst(grep,xargs) > to update the documents on how to code ksh builtins Are these documents included in the next ast-open release? Oh, and the usual question: When will the git be updated? :) > now to the nmake question > > look at src/cmd/ksh93/Makefile: you'll notice the SHOPT_* vars are defined > using == assignments > this makes SHOPT_* "state variables" > > the "%.o : %.c" metarule (in $INSTALLROOT/lib/make/Makerules.mk) is set up to > expand > in CCFLAGS any state vars referenced by the %.c file into properly quoted > -Dvar=value OK > if CCFLAGS is expanded outside of a metarule scope no state variables will be > expanded > > a similar mechanism expands only those -I options corresponding to header > files actually > included by the %.c > > so, given > SHOPT_EXTRA_BUILTINS == 1 > this test in the global makfile scope will always fail > if CCFLAGS == "*SHOPT_EXTRA_BUILTINS=1*" > > you would need to define SHOPT_EXTRA_BUILTINS the same in 2 different > makefiles > this is a situation we try to avoid because normal day-today building > does not use "bin/package make", and putting something like > SHOPT_EXTRA_BUILTINS > on the command line could (and most likely would) lead to separate builds > with different SHOPT_EXTRA_BUILTINS settings OK Does nmake support including other makefile fragments, e.g. does it have an #include statement? > if you really want to do this then the libcmd makefile already has provisions > for > allowing ksh to enable all -lcmd builtins in the ksh93 build > > limit the SHOPT_EXTRA_BUILTINS logic to the libcmd makefile > cmdlist.h will contain > CMDLIST(foo) > for each b_foo() built in libcmd.a > > then in the ksh93 makefile enable > SHOPT_CMDLIB_HDR == 1 > and data/builtins.h will #include <cmdlist.h> with CMDLIST() defined to > initialize the builtin table > > finally we can compare the coordinated build changes to src/lib/libcmd and > src/cmd/ksh93 > to the changes required by src/cmd/kshlib/cmdtst: > all cmdtst changes are localized to src/cmd/kshlib/cmdtst > > the main difference from the user perspective is that the cmdtst user will > need to > set up sibling bin and lib directories and add the bin dir to PATH before any > other bin dir that contains grep or the other -lcmdtst builtins > > bin/.paths > BUILTIN_LIB=cmdtst > LD_LIBRARY_PATH=../lib > lib/cmdtst.so Well, OK. The trouble I tried to avoid was to have a second libcmd.so.1 (called libcmdtst.so.1) floating around which has to link explicitly against Roland Mainz's version of busybox (https://raw.github.com/joyent/illumos-joyent/master/usr/src/cmd/ksh/builtins/alias.c). Having all of these builtins in one shared library would've made logistics much easier. Irek _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
