On 10/05/2018 02:54 PM, enh wrote: >> 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.
What does "replicating in soong" mean here? [googles...] https://android.googlesource.com/platform/build/soong/ "The build logic is written in go using the blueprint framework." You're using go as your build scripting language? >> (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. I was thinking it might help triage what's there and evaulate what's necessary. I'm all for removing unecessary stuff, on general principles. Unfortunately, when I wrote plumbing it's usually because I couldn't figure out how to get away with not doing it. >> Rob Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
