[Toybox] [PATCH] new Android toy: log

[enh]

On Sat, Jun 25, 2016 at 10:34 AM, Rob Landley <rob at landley.net> wrote:
> 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.

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.