[Toybox] building multiple configurations from one tree

[enh]

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.

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).

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.

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.

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.)

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.

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.