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. > 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...) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
