On Sat, Jun 25, 2016 at 10:34 AM, Rob Landley <[email protected]> wrote: > On 06/24/2016 12:36 PM, enh wrote: >> On Thu, Jun 23, 2016 at 11:06 AM, Rob Landley <[email protected]> wrote: >>> >>> >>> On 06/22/2016 05:53 PM, enh wrote: >>>> On Tue, Jun 21, 2016 at 8:53 PM, Rob Landley <[email protected]> wrote: >>>>> On 06/21/2016 05:29 PM, enh wrote: >>>>>> On Tue, Jun 21, 2016 at 2:13 PM, Rob Landley <[email protected]> wrote: >>>>>>> Don't #ifdef ANDROID on something that already depends on >>>>>>> TOYBOX_ON_ANDROID, we only compile it when it's buildable (compile-time >>>>>>> probes set the symbol). Typing "make log" at the command line assumes >>>>>>> you know what you're doing, and building an empty command isn't an >>>>>>> improvement. >>>>>> >>>>>> like i say each time this comes up :-) --- i need to be able to "make" >>>>>> on the host to be able to run all your stuff to generate the generated >>>>>> files. we could add bogus implementations to portability, but then you >>>>>> end up with quite a lot of fake android crap in there... >>>>> >>>>> Ah, we have had this discussion before. It's already there (since 2014): >>>>> >>>>> NOBUILD=1 make >>>>> >>>>> That regenerates headers then stops before trying to compile the result. >>>> >>>> okay, i can live with that. it was mildly convenient to be able to >>>> build for host and target from the same directory (and thus .config >>>> file), but i can live without. >>> >>> My master plan is to get android builds working under android systems, >>> so I hope to give you that ability _back_. :) >> >> a more realistic goal is building AOSP with toybox on a regular linux >> host. there is some interest in that (hermetic builds being an obvious >> good thing) > > The reason I became busybox maintainer way back when is I was extending > it to replace all the Linux From Scratch packages (initially in hope of > saving knoppix 100 megs). My Aboriginal Linux project > (http://landley.net/aboriginal/about.html) was a proof of concept that > this actually worked. > > It started by populating a build/host directory and setting > PATH=$PWD/build/host. Then it built a system with the same tools, then > built linux from scratch under the result. If the first of these three > stages is called "hermetic builds" now, I'm all for it. > > Building with $TOOLSET on an existing host is an important step towards > building with $TOOLSET on a new target. > >> but that would require either two copies of toybox in the >> tree or, more reasonably, some support for multiple .config files and >> multiple generated directories. > > I note that scripts/make.sh is a shell script. You don't need to use gnu > make to build the thing, the make plumbing is literally just: > > all: toybox > > KCONFIG_CONFIG ?= .config > > toybox_stuff: $(KCONFIG_CONFIG) *.[ch] lib/*.[ch] toys/*.h \ > toys/*/*.c scripts/*.sh > > toybox generated/unstripped/toybox: toybox_stuff > scripts/make.sh > > Which boils down to: > > all: toybox > toybox: $(DID_THESE_CHANGE) > scripts/make.sh > > I.E. it figures out if it needs to call scripts/make.sh and then does > it. The install targets are just scripts/install.sh with different > arguments: > > install_flat: > scripts/install.sh --symlink --force > > install: > scripts/install.sh --long --symlink --force > > uninstall_flat: > scripts/install.sh --uninstall > > uninstall: > scripts/install.sh --long --uninstall > > Now the downside here is it's a bash script, so it has #!/bin/bash as a > dependency. That's intentional because toysh should replace _bash_ (not > just posix sh), so I haven't restricted the feature set for dash or ash. > But if you needed it to run with a specific shell, that's probably doable.
the problem's not that, it's the need to be able to differentiate between NOBUILD=1 CONFIG_FILE=.host.config GENERATED_DIR=$(ANDROID_HOST_OUT)/blah/blah scripts/make.sh and NOBUILD=1 CONFIG_FILE=.target.config GENERATED_DIR=$(ANDROID_PRODUCT_OUT)/blah/blah scripts/make.sh because (unless you put my #ifdefs back) i can't use the same .config and generated directories for both. (even if we had the #ifdefs, being able to point to an arbitrary directory for the generated files would be independently useful to me because it would let me stop checking in generated files.) but like i said, no one's working on either of these things right now, so it probably doesn't make sense for you to look at doing anything until i can promise i'd actually investigate using it in a reasonable timeframe. maybe next year... >> this isn't something that anyone's currently actively working on >> though. we have other major build system upheavals to get through >> first :-) > > I'm working on it, but I $DAYJOB isn't giving me a lot of air at the > moment. (I'm either riding down a fourth startup or I'll get > retroactively paid for the past 6 weeks. No idea which yet.) > >> (bionic is soong-only at this point in master. [most of] the makefiles >> have been deleted.) > > You can delete toybox's makefile for the actual build and just run the > shell scripts directly (at least to get a host version), and all we use > from kconfig is the .config file. (And I could probably make a sed > invocation generate a defconfig, or repurpose the scripts/config2help.c > plumbing. I've been meaning to write a full kconfig replacement for > years, it just hasn't made it up the todo list...) the kconfig stuff stopped working for me a while back (long enough that i forget why) --- i've just edited .config directly for a very long time now. (i think there was a thread on the list about using the awk version instead around that time.) > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
