[Toybox] --version

[Rob Landley]

On Sat, Apr 18, 2015 at 4:59 PM, enh <enh at google.com> wrote:
> On Fri, Apr 17, 2015 at 12:47 AM, Rob Landley <rob at landley.net> wrote:
>> On Wed, Apr 15, 2015 at 12:51 PM, enh <enh at google.com> wrote:
>>> in ad602aa127e44eade76fbb05fd27ee8f5825282a you added a --version that
>>> outputs a constant string defined in main.c. i just wanted to point
>>> out that -- for the foreseeable future until toybox is "mostly done"
>>> -- this means Android will pretty much always lie. we'll be some
>>> random SHA ahead of that version. (right now, for example, we're far
>>> ahead of 0.5.2 but will claim to be 0.5.2.)
>>
>> Yup. I don't really have a good answer to that.
>>
>> I suppose I can add plumbing that _if_ it's built from git (release
>> tarballs aren't) then use the git describe --tags output, otherwise
>> fall back to the VERSION file? Hmmm...
>>
>>> you mention in the checkin comment that you don't trust yourself to
>>> keep things up to date --- did you consider setting it in the makefile
>>> instead and grepping the version out of the www/ directory?
>>
>> Yes, and I'm even less likely to remember to update it there.
>>
>>> or, if you plan on having an rpm spec file or equivalent, from there?
>>
>> I'm all for people packaging toybox in RPM. And in .deb. And in gentoo
>> ebuilds for portage. And in pacman for arch. And in bitbake for
>> openembedded and yocto and tizen. And in slack packages. And in
>> buildroot. And maybe android apk works in there somehow, or ipkg or
>> opkg. And apparently sabotage is creating one called "butch"...
>>
>> Am I having toybox depend on any of that? Nope.
>>
>>> _i_ don't care, but if people report toybox-on-Android bugs to you
>>> rather than to me, you might have a confusing time with the current
>>> setup.
>>
>> Good point.
>>
>> Try now?
>
> https://android-review.googlesource.com/#/c/147441/ adds the
> equivalent 'git describe' to the Android.mk. for some reason my tree
> with the remote has 0.5.1 and 0.5.2 but a regular tree only has 0.5.0.
> but the hash is the more useful part anyway so this still seems like a
> step in the right direction.

Cool. The 12 bytes thing is from
http://landley.net/notes-2013.html#08-10-2013 by the way.

>> I have static strace binaries at http://landley.net/aboriginal/bin for
>> various architectures but I hadn't hugely noticed the need for regular
>> version updates on them? (Modulo that time powerpc system calls
>> changed...)
>
> clearly not an aarch64 user...

I want to be but aboriginal's old "last gplv2 release" toolchain made
from gcc 4.2.1 and binutils 2.17 doesn't include support for it. (I
had to move forward in git to right before the license switch just to
get armv7 in binutils, and still need to do the same for the
compiler.) Since I distribute toolchain binaries as part of that
system, would be shipping gplv3 binaries if I switched, and that's not
something I'd want to do without a large corporate entity with deep
pockets standing between me and the resulting legal liability.

I'm looking forward to being able to switch to llvm so I can start
supporting/testing more architectures. Alas, too many other things to
do this week...

> btw, is it deliberate that you have to do "toybox --version"? that,
> say "top --version" says "top: Unknown option version"?

Not really, just a general reluctance to pollute the namespace of the
other commands.

For sed --version needs to produce a string that includes "gnu sed
X.Y" to placate autoconf stupidity, which is why it says "this is not
gnu sed 9.0". Otherwise various builds get stupid and go down
codepaths last tested in the 1980's that assume they're building on
HPUX.

Also, a number of commands feed a constant NULL (or more often 0) to
the optstr field of NEWTOY() which disables command line option
parsing completely. Everybody gets toys.argv[] passed through
verbatim, so they can parse their own command line arguments if they
like, but the lib/args.c stuff doesn't get called so GLOBALS() is left
zeroed out, toys.optflags is left zero, and toys.optargs is set to
NULL. This has the advantage that for builds where _all_ commands have
disabled option parsing this way (such as standalone command builds),
the option parsing logic drops out and you save a couple kilobytes.

Huh, but now that I think about it --help is getting called _before_
all that (from toy_singleinit() in main.c) and that's the logical
place to put --version too, if you wanted it to be available from
every command. Of course that implies that instead of saying 0.5.2 it
should say "toybox 0.5.2"...

To answer your question, "I hadn't thought about it, and am open to
suggestions." I haven't really got a use case in mind here, I dunno
what end users _want_ from this bit. I don't list --help in the help
text for chicken and egg reasons. I probably should in at least the
toybox help message in Config.in. I _do_ list --version in the toybox
help message, and if we genericize --version then I suppose that would
be the place to say that --version applies to any toybox command?

Rob

 1429405289.0