[Toybox] mac CI breakage

[Rob Landley]

On 6/2/22 00:47, enh via Toybox wrote:
> the mac build on github has been broken for a few days:
> 
> Run make
> scripts/make.sh
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> readlink: illegal option -- f
> usage: readlink [-n] [file ...]
> $GENDIR=generated cannot include $***
> make: *** [toybox] Error 1
> Error: Process completed with exit code 2.
> 
> (from https://github.com/landley/toybox/runs/6682393952?check_suite_focus=true
> <https://github.com/landley/toybox/runs/6682393952?check_suite_focus=true>)
> 
> funnily enough, it works fine for me locally because i'm on macOS 12, and one of
> the few improvements i've actually noticed in it is that readlink now has a -f
> option. i've attached a patch that switches the CI over to just testing the
> current macOS release, but 10.15 is actually still getting security updates
> (until the end of this year, if history is any guide).

Applied.

> note that it's possible to tell the compiler you're _targeting_ an older macOS
> version, so we could do that if you don't care about _building_ on old versions
> of macOS [without installing a custom readlink] but still want to support
> _running_ on them...

If we build an older target binary will it run on newer OS vesions? If so that's
probably a good thing to do.

Longer-term, I'm trying to come up with a build.sh that compiles just the toybox
commands it needs to build itself, without running any configure plumbing,
needing to probe anything about the host (assume "no" for all checks), or
pulling in any optional libraries. Just a cc command line building a list of *.c
files with a snapshot .config and generated/*.h so the only binary you run for
that build is the compiler. Then you can run the config and such with the
resulting binaries. (Basically a "make airlock" variant, except it's a canned
bootstrap airlock.)

Alas, I need to get toysh to the point it runs make.sh and install.sh first. And
before _that_ I'm trying to get toysh to run test.sh. Working on it...

Rob

(It would be easier if I had one generated/generated.h I could #include instead
of needing 5 of them, but config.h needs to go before portability.h, and then
the other 4 happen after #including everything else so the full range of types
is available. I suppose I could keep config.h separate and have a
generated/toys.h that #includes the other 4, and then when providing a canned
generated directory as cc -I it would only need two headers in it. They're
separate so they can be rebuilt as needed, but a hand-crafted canned file can
collate...)