[Toybox] Toybox Installer/setup routine?

[enh]

On Wed, Sep 11, 2019 at 2:28 AM Rob Landley <rob at landley.net> wrote:
>
> On 9/8/19 5:29 AM, Denys Nykula wrote:
> >> It's probably easier to maintain a makefile for llvm, cmake is terrible.
> >
> > Unsure if easier to maintain, but easier to make, yes. Will try and see.
>
> make is like vi: utterly terrible and ubiquitously standardized.
>
> Modulo the gnu/dammit crazies embraced and extended it so bsd make can't run any
> linux makefiles. So I need to write a make that does gmake the way toysh does bash.
>
> 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.

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

> >> If you don't mind /share and /include at the top level.
> >
> > Looking up files in shell a lot, I do want /local and these dirs in root. Not
> > fond of extra depth in /home, /mnt and, to some degree, /var, either.
>
> There are standard linux top level directories. Those aren't it. You're welcome
> to throw symlinks all over the place if you like, but it's not a standard and
> ain't gonna be.
>
> >> My mkroot script creates a minimal directory hierarchy (enough to install linux
> >> from scratch into) in 3 lines:
> >>
> >> mkdir -p "$ROOT"/{etc,tmp,proc,sys,dev,home,mnt,root,usr/{bin,sbin,lib},var} &&
> >> chmod a+rwxt "$ROOT"/tmp && ln -s usr/{bin,sbin,lib} "$ROOT" || exit 1
> >
> > Mkroot is useful. Regarding allnoconfig, where should I read about kconfig CLI
> > helpers if they exist?
>
> make help (in toybox or in linux), and there's something under the Documentation
> directory in the kernel but they keep moving the files there. (And they've
> apprently rewritten the documentation in rust, which I was unaware was an option?)
>
> https://www.kernel.org/doc/Documentation/kbuild/kconfig.txt
>
> I also have my own compressed version of the config files:
>
>   http://landley.net/aboriginal/FAQ.html#dev_miniconfig
>
> Which I tried to submit upstream multiple times back when I still engaged with
> linux-kernel:
>
>   https://lwn.net/Articles/161086/
>
> *shrug*
>
> > Currently to remember because of which dependency I keep
> > a certain option in my config and see if I maybe can remove it since I no
> > longer use this or that device, I have this ad hoc reverse lookup:
> >
> > #!/bin/sh
> > # $ kwhy ACPI_WMI
> > # DELL_WMI
> > # IDEAPAD_LAPTOP
> > # ...
> > find /src/linux/ -name Kconfig -not -path '*scripts*tests*' -exec perl -0pe 's/\
> > nconfig (.+)(\n[ \t]+.*)*\n[ \t]+depends on.*[^!\w\n]('$1')[^!\w].*/\n$1\n/g;s/(
> > ^|\n)[^A-Z\n].*/\n/g;s/\s+/\n/g;s/^\n//' {} +
>
> See you and raise you:
>
> https://github.com/landley/aboriginal/blob/master/more/miniconfig.sh
>
> >>> Head with negative -n value is used in Linux kernel build for atomics checks,
> >>
> >> Huh, what architecture/config requires this? (I've been building the kernel with
> >> toybox for years now, and built it with mkroot yesterday. Didn't see this. The
> >> only thing I'm finding with grep isn't building the kernel, it's building perf
> >
> > scripts/atomic/check-atomics.sh:
> > NEWSUM="$(head -n -1 ${LINUXDIR}/include/${header} | sha1sum)"
> >
> > Build continues, just prints distracting warnings at the beginning. Wrote this
> > down when trying to build as much as possible with LLVM and note all that
> > might have been going wrong.
>
> There's more or less annual bursts of interest in that:
>
> 2017: https://lwn.net/Articles/734071/
> 2018: https://www.phoronix.com/scan.php?page=news_item&px=Clang-Kernel-2018
> 2019: https://www.phoronix.com/scan.php?page=news_item&px=Google-2019-Clang-Kernel
>
> Going back to... 2010 I think? Yeah looks like, 2010:
> https://lwn.net/Articles/441018/
>
> 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.)

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.

> *shrug* Historically someone will write a new one that gets traction eventually.
>
> >>> if ! sed -n -e '/^# Generated by .*libtool/q0;4q1' "${f}"; then continue; fi
> >>
> >> Ok, so you need the exitcode extension to q, and never previously mentioned it
> >> on this list. Right, easy enough to add...
> >
> > Haven't mentioned because it's not a bottleneck and is in my own todo list.
>
> Just added it, and a couple other things while I was in the area.
>
> (The largest part of the patch was the error checking for q123 having something
> other than digits after it.)
>
> >>> There are also patch -f and find -newerXY
> >>
> >> Let's see, we don't check "Prereq:" lines, I don't remember implementing
> >> querying /dev/tty for a filename if the one in the patch isn't there (we just
> >> fail), and although we _warn_ about possibly reversed patches that's all we do.
> >> So our current behavior _is_ -f already, and it sounds like I should
> >> accept-but-ignore the option?
> >
> > Yeah it's about the tty prompt. Portage checks the patch before applying and
> > passes -f to prevent this freeze, with --dry-run to not pollute the sources.
>
> We don't do the tty prompt.
>
> > It's an old option likely used in other build tools, so if toybox behaves
> > like it's there by default, adding a noop -f flag can be useful.
>
> My patch.c is dirty because it's got most of fuzz support added. I should finish
> that up and commit it...
>
> > /portage/eclass/epatch.eclass:
> > # Generate some useful debug info ...
> > ${patch_cmd} --dry-run -f < "${PATCH_TARGET}" 2>&1
> >
> > Gentoo duplicated this in another place, adding two more options to imitate
> > the same dry run behavior in case of a mismatch, dropped support for standard
> > patch and required GNU everywhere. This seems dirty and I'm in favor of
> > letting extra options other than -f remain broken.
>
> I wonder what funtoo does?
>
> > /lib/portage/python3.7/phase-helpers.sh:
> > ebegin "${prefix:-Applying }${f##*/}"
> > # -p1 as a sane default
> > # -f to avoid interactivity
> > # -s to silence progress output
> > # -g0 to guarantee no VCS interaction
> > # --no-backup-if-mismatch not to pollute the sources
> > ${patch_cmd} -p1 -f -s -g0 --no-backup-if-mismatch \
> >   "${patch_options[@]}" < "${f}"
>
> Got -p1, got -s, don't have -g0? (What?) And we don't --backup-if-mismatch anyway.
>
> Right, so they need _3_ NOP options....
>
> >> 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.
>
> > Xdg-utils look for recently installed desktop apps to update users' file
> > association tables, comparing app inode change with table modification.
>
> I get atime, ctime, and mtime from stat. Imma use them for a, c, and m here and
> call it good.
>
> > /lib/portage/python3.7/preinst-qa-check.d/50xdg-utils:
> > find_args+=( -newercm "${d}"/mimeinfo.cache ) || missing=1
> >
> > Difference between content birth and inode change is from BSD. This doc
> > says that any B test should return false on Linux filesystems, most
> > details are in the section, More on age ranges.
> > http://www.softpanorama.org/Tools/Find/selecting_files_by_age.shtml
>
> First time I looked at that website it had a long rant about how Linus has
> terrible judgement and everything in Linux is wrong. *shrug* Never looked at it
> again.
>
> Ok, b always fails, t parses the next argument (can presumably only have one),
> and and the association of computing machinery is the usual stat values.
>
> And I am riffing on names which means I am sleep deprived, and should probably
> do this in the morning. Guten blinking nacht.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net