[Toybox] Toybox Installer/setup routine?

[Rob Landley]

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.

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

(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