[Toybox] Toybox Installer/setup routine?

[enh]

On Fri, Sep 13, 2019 at 1:48 PM Rob Landley <rob at landley.net> wrote:
>
> On 9/11/19 4:42 PM, enh wrote:
> > On Wed, Sep 11, 2019 at 2:28 AM Rob Landley <rob at landley.net> wrote:
> >> That said, once such a thing exists and isn't GPLv3, using it isn't _that_ bad.
> >> (I'm all for replacing make, but "with what" still isn't answered at the design
> >> level. If it was gonna be ninja, why would ninja have been replaced with
> >> whatever's generating ninja now? And somebody other than Google would be using
> >> it. *shrug* Maybe that'll resolve eventually, but it hasn't yet.)
> >
> > ninja's a lot more widely used than you seem to think, but the mistake
> > is that you're considering it to be a replacement for make. it's not:
> > it's a replacement for make's back-end. so cmake, for example, can use
> > ninja now, and every cmake-using project may well be using ninja. the
> > point of ninja is that folks can keep dicking about with what the
> > "build system" looks like without having to keep reimplementing the
> > back-end stuff.
>
> Why does make need a back-end? It's repeatedly calling the compiler and linker.

not only is it not directly a replacement for make, it's also not a
back-end for specifically _make_ (though Android's kati was a hack
that let it be that in the early stages of our move away from make),
it's a back end for build systems. your home-grown "configure" could
output a ninja file, for example. (but since you're unlikely to ever
grow to a size that would really win anything back, .)

when you have millions of files (on the one hand) and tens of cores
(on the other), making good use of that gets interesting. when you can
also have a completely different execution model that builds remotely
(on thousands of cores) and minimizes the amount of stuff pulled back
you your local machine (because you don't actually need any of those
.o files, say), well, maybe it's not a great software engineering idea
for everyone to have to rewrite that from scratch too, just because
they're wedded to make or cmake or xcbuild or msbuild or gradle or
meson or whatever.

https://ninja-build.org/manual.html talks about this more.

but as long as your build only takes a few seconds on a single core,
you're probably not going to get anything from ninja. (you don't
really need to invent sewers until you're living in cities either.)

> > https://github.com/ninja-build/ninja/wiki/List-of-generators-producing-ninja-build-files
> > lists some of the more popular front ends. (i'm also aware of
> > companies other than Google that have an internal build system that
> > now uses ninja as the back-end.)
>
> At JCI last year I hung out with the guy rewriting their build system in cmake.
> He could talk for hours about weird bugs and version skew in cmake, and he was
> trying to figure out how to _not_ be the single point of failure for the entire
> department when it came to build systems, because the cmake files everybody else
> were trying to write kept doing things subtly wrong and introducing all sorts of
> bugs he got called in to fix. (Many of which I heard about because I'm strangely
> good at debugging things I know nothing about, so he'd come over to bounce the
> latest bug off me whenever he got blocked so I could ask stupid questions or
> suggest debugging approaches.)

as far as i can tell, if you're only targeting one OS, cmake just
causes you problems. folks who're targeting multiple OSes, especially
if one of those is Windows (and you're not just cross-compiling like
we do), seem to like it though.

> (Because of course when you have an overcomplicated yocto build you've already
> outsourced maintenance of to Wind River, the logical thing to do is stick it in
> a jenkins build running in a drupal container and hook it up to your local
> commercial github instance with integration to IBM's Rational bug thingy _and_
> Jira because different managers prefer different tools and you, personally,
> report to three managers at once for the duration of the contract...)
>
> >> The problem is the linux-kernel development community has been circling the
> >> wagons and sniffing its own farts for many years now (that's ANOTHER periodic
> >> repost, ala
> >> https://www.zdnet.com/article/graying-linux-developers-look-for-new-blood/ and
> >> https://thenewstack.io/growing-new-linux-kernel-developers/ and ALSO since about
> >> 2010), and they don't regression test anything but gcc upstream. And people
> >> outside the kernel clique have shown less and less interest in engaging with the
> >> kernel clique...
> >
> > i think the corner has been turned here actually. (obviously we've
> > been enjoying clang-built kernels for a few years now, but i'm talking
> > about upstream too.)
>
> Not surprised, gcc is end of life. I need to try to get
> https://github.com/thegameg/j2-llvm merged upstream...
>
> > a little bit left to go to ensure that there's continuous integration
> > to stop folks from breaking things with GCCisms, and we managed to
> > keep an intern busy this summer working on both the kernel and clang
> > sides, but i don't think the old state of war exists any longer.
>
> The guy maintaining uClibc-ng (instead of using musl or bionic) listed 4
> architectures that uClibc supports that musl doesn't yet as his reason for still
> maintaining the old project.
>
>   https://lists.uclibc.org/pipermail/uclibc/2017-March/049251.html
>
> I've had a todo item to try to add support for those 4 architectures to musl so
> the old thing can just die already. There's a similar problem with llvm, a lot
> of embedded architectures aren't supported by llvm yet, so they have no _choice_
> but to use glibc in things like musl-cross-make.
>
> >>>> Um, looking at newerXY... there are only 3 times in stat, create, access,
> >>>> modification. What's this "birth" nonsense? Why is Hurd tracking that
> >>>> differently then linux, and why would anyone care? (Would making b and c
> >>>> synonyms break anything?)
> >>>>
> >>>> I can see -newermt 123456789 being useful, though...
> >>
> >> That's an actual new feature, I might cut a release first.
>
> Working on it now anyway. :)
>
> Darn cold is slowing me way down though...
>
> Rob