[Toybox] getconf NPROCESSORS_ONLN broken

[enh]

On Thu, Oct 4, 2018 at 8:18 PM Rob Landley <rob at landley.net> wrote:
>
> 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...

don't worry, i was planning on sending you missing ones. i just don't
want my patches to get too far out of sync with upstream.

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

not relevant --- since NDK r14 ("unified headers") you get the same
headers regardless of API level. that already "just works".

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

i'm kind of resigned to having to explicitly build the help, flags,
and arrays binaries and run them, and they all seem like they're
pulling their weight anyway. i just don't want to encourage too much
random other stuff, because i need to replicate all your shell scripts
in soong.

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

no, i'm after "less overall" rather than "smaller chunks". stuff like
library probes and the like are fine, because that's just hard-coded
for me anyway.

> Rob