On Fri, Sep 13, 2019 at 1:48 PM Rob Landley <[email protected]> wrote: > > On 9/11/19 4:42 PM, enh wrote: > > On Wed, Sep 11, 2019 at 2:28 AM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
