On Fri, 4 May 2012 16:33:24 +0200 Irek Szczesniak wrote:
> On Fri, May 4, 2012 at 7:15 AM, Glenn Fowler <[email protected]> wrote:
> > 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?
I'm checking with dgk on the progress today
> Oh, and the usual question: When will the git be updated? :)
the git will be updated with the beta update
we located the problem and it shouldn't happen (in this way at least) again
> Does nmake support including other makefile fragments, e.g. does it
> have an #include statement?
many different ways
* --file=file (on the command line)
* --global=file (on the command line, user makefile vars override global
makefile vars)
* include [-] "file" (- for dontcare if it doesn't exist)
* :ASSERTION_NAME: (if not already defined includes ASSERTION_NAME.mk)
* create src/cmd/nmake/Localrules.mk and then nmake install from
$INSTALLROOT/src/cmd/nmake
Localrules.mk will not be clobbered by new package distributions
you can also insert command line args from a top level component dir (arch/...)
by placing the args, one per line in one of these files { Makeargs, makeargs,
Nmakeargs, nmakeargs)
> > 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.
"easy" is a relative term
for a space-optimized ksh implementation I can see your point
in that case I'm guessing ksh is built with SHOPT_CMDLIB_HDR==1 to make all
-lcmd builtin
I'm pushing alternative -lcmdfoo a bit because { *grep xargs } won't be the
last builtin candidates
and we can probably expect many more non-posix-section-1 builtins that would
not be appropriate for -lcmd
we don't want to get bug reports on frankenstein ksh builds that will be hard
to reproduce on our side
having separate non-standard plugin libs will help isolate problems to
either ksh or the plugins
we modeled the .paths builtin lookup after PATH lookup
if there weren't builtins you would have to populate a PATH dir with a.out's
I have to double check with dgk but I believe a .paths file can have more than
one BUILTIN_LIB statement, so you could install libcmdtst.so in the same dir as
libcmd.so
and just add BUILTIN_LIB=cmdtst after BUILTIN_LIB=cmd
does the busybox ksh link against libshell.so or libshell.a?
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
