[Toybox] building multiple configurations from one tree

[Rob Landley]

On 06/30/2017 01:13 AM, enh wrote:
> i've mentioned this a few times, but i have a concrete example now.
> with treble [https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html]
> there will be a copy of mksh and toybox on the /vendor partition in
> addition to the copies on the /system partition. this lets us upgrade
> /system's copy at will without worrying about breaking any of the code
> on /vendor (because it'll only be allowed to access the /vendor shell
> and utilities).
> 
> so far so good. and ideally you'd want them to be the same. but the
> functionality and libraries available to /vendor code differ from
> /system code. in particular, some of the Android extensions to SELinux
> aren't available for /vendor. which basically means getprop -Z and
> restorecon can't be built.

Which sounds like the "building with the NDK" problem all over again.

> short term we could provide dummies in portability.h:
> 
> #if __ANDROID_VENDOR__
> static inline int f(...) { error_exit("f unimplemented on /vendor"); }
> static inline int g(...) { ... }
> #endif
> 
> and then -D__ANDROID_VENDOR__ when we build the /vendor copy.
> 
> but i think it would be better if we just don't have restorecon and getprop -Z.
> 
> i can send a patch that makes getprop -Z require a new "has Android
> SELinux extensions" configure variable, but there's still no easy way
> for me to override stuff in the .config file (which would let me
> control both this and the availability of restorecon).

I can add a compile time probe, but you're not using my build scripts.
I'd also point you at miniconfig
(http://landley.net/aboriginal/FAQ.html#dev_miniconfig) but again...

(Sigh. I designed infrastructure for this sort of thing.)

> if config.h instead of
> 
> #define CFG_RESTORECON 1
> #define USE_RESTORECON(...) __VA_ARGS__
> 
> said
> 
> #ifndef CFG_RESTORECON
> #define CFG_RESTORECON 1
> #endif
> #if CFG_RESTORECON == 1
> #define USE_RESTORECON(...) __VA_ARGS__
> #else
> #define USE_RESTORECON(...)
> #endif
> 
> and global_union could have
> 
> #if CFG_RESTORECON
>         struct restorecon_data restorecon;
> #endif
> 
> i could -DCFG_RESTORECON=0 (and not have restorecon.c in the files
> list) when building the vendor copy.

True. Not an ideal solution. And roughly equivalent to hitting config.h
with sed. There's no dependency resolution going on there, so might as
well just:

sed -E '/ (CFG|USE)_RESTORECON /{s/1$/0/;s/__VA_ARGS__//}' \
  generated/config.h

But again, not an ideal solution. :)

> i have another couple of configurations lurking in the wings too.
> they're likely to not have any SELinux, and might want to support
> different subsets of commands.

Grrr. I thought you could feed a KCONFIG_ALLCONFIG to defconfig, but
looking at the kconfig source (copied from 2.6.12 back in the day, I've
meant to replace it _forever_) it's only reading it for
allno/yes/mod/randomconfig. Sigh.

And even if that did work it wouldn't help you because you've
snapshotted the generated files.

Right, I need to redo my build so it's something you can actually _use_,
and step 1 of that is getting the existing Ninja build to run the
Android.mk file you've got. But "apt-get install ninja-build" in Ubuntu
14.04 was followed by:

  $ ninja -f Android.mk
  ninja: error: Android.mk:17: expected '=', got ':'
  LOCAL_PATH := $(call my-dir)
             ^ near here

Which put it back on the todo list. :)

Then again Ubuntu 14.04's "aptitude show ninja-build" says:

  Homepage: http://martine.github.com/ninja/

Which is 404 (it appears to be ninja-build.org now) so that's possibly a
really old version. I should try building it from source...

> i think previously you've been thinking along the lines of making it
> easier to work with multiple generated/ directories, but i'm wondering
> whether it might be more convenient to just generate something that
> can be overridden up front? (it would certainly be a good fit for my
> uses.)

Both need to happen, but you've got a use case sitting in front of you
right now so let's fix that.

> i haven't actually tried this yet, so maybe there's something that
> won't work. but if this seems like a reasonable thing to try i can
> have a look. i'll probably have a look anyway, because having multiple
> copies in the tree or having local #if __ANDROID_VENDOR__ patches seem
> like significantly worse choices and i don't want to be without an
> alternative when the music stops and we have to sit somewhere...
> though dummy implementations is probably the smallest hack if it comes
> to it.

90% of my toybox work is on the weekends these days. (Startup $DAYJOB
has missed 2 of the last 3 paychecks so I'm currently doing a consulting
gig on the side of that, which means my weekdays are pretty thoroughly
shot right now. I'm just by fiat saying "weekends are for toybox!" and
ignoring 'em both during that).

Which means I get 2 days to poke at this now, if you think it's worth
trying to fix it up.

The current problem seems to be that your build system is using a
snapshot of the generated directory checked into your repo, and now you
need multiple build contexts with different configurations. We could
hack up those saved configs with more #ifdeffery, or hit them with sed,
but long-term getting the generated/ stuff generating under your build
seems like a better solution? I'd like to at least get _started_ on that.

Which means I probably need to reproduce your build context. I could
reinstall AOSP on the big machine (which is nontrivial because if I
recall I need to clear off something like 250 gigabytes of disk space,
and it currently has 4 gigs free).

But the BIGGER problem is last I poked at that it was a giant monolith
that was non-obvious how to focus on individual bits of it. (I had a
series of web pages to read about that, and a youtube presentation. It's
on the todo list. But those resources were for "M" and we're up to "O"
now, so I expect a lot's changed anyway...)

Ideally I'd like to reproduce the android build context in an otherwise
minimal chroot, but I have no idea how to _start_ going about that.
Other than installing, successfully running, and then reverse
engineering AOSP.

Rob