[Toybox] getconf NPROCESSORS_ONLN broken

[Rob Landley]

On 10/04/2018 06:06 PM, enh wrote:
>> Possibly what I need is an #ifdef/#else staircase for all those symbols in a
>> header file, which can be generated once from the actual posix spec and then
>> ignored. (I don't care about ugly in header files. I just don't want the data in
>> two places that have to be kept in sync...)
> 
> i think that's overkill. we demonstrably don't have to care about
> anything outside the subset that GNU supports. (and in practice it
> seems like there are really only a tiny handful that are actually
> used.)

Indeed, but it's hard to predict what that handful _is_. It's one of them
"nobody uses more than 20% of the features, but they're never the same 20%"
things...

An if/else staircase in the header _and_ a list of symbols in the command is
exactly what I was trying to avoid. That said, an if/else staircase in the
command is at least contained in one place.

Or would could just say "this is tested against bionic, musl, and glibc, and
anything else can define the symbols or add itself to portability.h". I have a
vague desire to make toybox build against older ndk apis, but am unlikely to
have bandwidth before they're the rest of the way obsolete. (Modulo I'm not sure
kit-kat will ever die at this point.)

> i think my patch to add the pathconf variables is more useful ---
> there are real live instances of that in the AOSP build.

I'll probably apply it as-is tomorrow, it's just one of those diffs that removes
enough code it's hard to read through, and I'm out of brain to think through it
today. (Didn't get home until 6 and had a 7:30 appointment just now wrapping up...)

> note that i also have an orthogonal interest in going in the direction
> of my patches: if i'm going to move AOSP to toybox, i'll end up
> replicating your build scripts in soong. so as far as i'm concerned,
> the less that's done there, the better...

The makefile tries hard to just be a wrapper, it boils down to a call to
scripts/make.sh. You can "make clean; make defconfig; scripts/make.sh"
And "make sed" and "make test_sed" stuff is calls to "scripts/single.sh sed" and
"scripts/test.sh sed". I.E. the build is written almost entirely in bash. :)

I should split scripts/ up into the actual build plumbing, a directory of tools
like bloatcheck and findglobals and showasm, and the test suite plumbing.

Hmmm, possibly the test suite plumbing should move under tests/ somehow...

In terms of eliminating unnecessary build plumbing, the tagged array stuff
(scripts/mktags.c) is the other big chunk of preprocessing, which is really
there to make a combined array/enum construct where you have a string name for
each entry _and_ a symbol of the same name resolving to the index of that entry
in the array. I would LOVE a way to do this with macros instead. (I can
stringify, but how do I get an increasing symbol number that goes up by one each
time it's referenced? I'd need INCREMENT(previous) to nest +1+1+1+1 and it's not
obvious how, which is prsumably why gcc has a __COUNTER__ macro, which is fiddly
and which I dunno if llvm implements it...

  https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Ah yes, it does:

  https://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros

I've been doing things via preprocessing on the assumption they'd be portable.
(It's either C code that runs on the host, or it's using standard command line
utilities that toybox itself implements...) But if things like __COUNTER__ are
better for you I'll see if I can simplify?

(I can also break up make.sh into multiple smaller scripts if that would help...?)

Rob