[Toybox] [PATCH] new Android toy: log

[Rob Landley]

On 06/24/2016 12:36 PM, enh wrote:
> On Thu, Jun 23, 2016 at 11:06 AM, Rob Landley <rob at landley.net> wrote:
>>
>>
>> On 06/22/2016 05:53 PM, enh wrote:
>>> On Tue, Jun 21, 2016 at 8:53 PM, Rob Landley <rob at landley.net> wrote:
>>>> On 06/21/2016 05:29 PM, enh wrote:
>>>>> On Tue, Jun 21, 2016 at 2:13 PM, Rob Landley <rob at landley.net> 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