[Toybox] Toybox Installer/setup routine?

[Rob Landley]

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

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

*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