On Fri, Jul 15, 2016 at 5:43 PM, Barret Rhoden <[email protected]> wrote: > > Minor comments below.
Okee doke. On 2016-07-12 at 16:43 Dan Cross <[email protected]> wrote: > > This is a Makefile, a patch, and a line in the top-level > > Makefile bringing in BASH for Akaros. I've been using this > > as my shell for a few months now. > > > > Change-Id: I09032cf55dc596f04cdc4ed4f741c9bddd2d78a2 > > Signed-off-by: Dan Cross <[email protected]> > > --- > > Makefile | 1 + > > tools/sys-apps/bash/Makefile | 57 +++++++ > > .../sys-apps/bash/akaros-patches/bash-4.3.30.patch | 179 > +++++++++++++++++++++ > > 3 files changed, 237 insertions(+) > > create mode 100644 tools/sys-apps/bash/Makefile > > create mode 100644 tools/sys-apps/bash/akaros-patches/bash-4.3.30.patch > > > > diff --git a/Makefile b/Makefile > > index cf34227..5a95b57 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -687,6 +687,7 @@ apps-install: $(app-dirs-install) > > @$(call make_as_parent, -C tools/apps/ipconfig install) > > @$(call make_as_parent, -C tools/dev-libs/elfutils install) > > @$(call make_as_parent, -C tools/dev-util/perf install) > > + @$(call make_as_parent, -C tools/sys-apps/bash install) > > Will this conflict with people using busybox, since bash is now invoked > from mon_shell? Basically, between bash and busybox, whatever was built > last wins, which is whichever happens to be lower in the apps-install > list. > That is correct. I'm anticipating no one will want to build/run busybox shortly. > My setup isn't quite ready to use bash, and I get a few errors like > this: > > /_init_brho.sh: line 1: bind: warning: line editing not enabled > /_init_brho.sh: line 1: bind: -c: invalid option > bind: usage: bind [-lpsvPSVX] [-m keymap] [-f filename] [-q name] [-u > name] [-r keyseq] [-x keyseq:shell-command] [keyseq:readline-function or > readline-command] > > (basically bind is just mucked up, which you mentioned you sorted out > elsewhere.) > I wouldn't say I sorted it out; the solution is to invoke 'bind' by pathname as '/bin/bind' since 'bind' is a builtin in Bash. One could try, 'alias bind=/bin/bind' and then run the builtin bind using, 'builtin bind' if one wanted, but I don't think that helps all that much for scripts. > +++ b/tools/sys-apps/bash/Makefile > > +########## Generic Infrastructure > > You've got a few changes to the generic infrastructure that probably > aren't necessary. For instance, > > > +%.tar.gz: > > + $(Q)wget $(fetch-url) > > This doesn't hurt bash, but the default should have worked: > > %.tar.bz2 %.tar.gz %.tbz: > $(Q)wget $(fetch-url) > Hmm. I changed that because it wasn't clear to me why we would care about anything other than the compression type used by a particular program. If we want to keep this generic, I would argue it should be in the Makefrag. > +akaros-patches := akaros-patches/bash-4.3.30.patch > > This breaks the 'version subdir' approach of the other packages. If > that's necessary, then we can change things. Original was this: > > akaros-patches := $(sort $(wildcard akaros-patches/$(version)/*)) I'm happy to make that change. > +PHONY += mrproper > > +mrproper: > > + $(Q)rm -rf $(src-dir) > > + > > +.PHONY: $(PHONY) > > For elfutils, I also did a make uninstall. Does bash not support > that? I tried make uninstall manually, and it tried uninstalling from > my host OS... Something wrong with the prefix setting? > x86_64-ucb-akaros-size bash > text data bss dec hex filename > 867071 36720 28176 931967 e387f bash > rm -f /bin/bash /bin/bashbug > rm: cannot remove ‘/bin/bash’: Permission denied > make: *** [uninstall] Error 1 > > To some extent, I'm OK merging this as is. But I'd like to get a > feeling for what is and isn't necessary for certain packages. > What happens if you try, 'make uninstall DESTDIR=$KFS_ROOT' ? I'm on the fence but leaning against an 'uninstall'. If we have an uninstall, I think it should be a separate target; 'mrproper' should be for getting this directory back to a pristine state, right? Removing the installed binaries there is a bit surprising. On a related note, do you normally have a git repo for bash? > I do not. I don't think we should be making one because I'd like us to minimize the changes we make to bash, and possibly send them upstream for incorporation into the mainline distribution. - Dan C. -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
