[Toybox] --version

[enh]

On Sat, Apr 18, 2015 at 6:01 PM, Rob Landley <rob at landley.net> wrote:
> 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.

yeah, it was the lack of analogy with --help that surprised me.

> Of course that implies that instead of saying 0.5.2 it
> should say "toybox 0.5.2"...

"toybox 0.5.2 (not gnu sed 9.0)" :-)

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

i don't have a strong opinion. for Android it probably doesn't matter
--- my assumption is that people are more likely to refer to "Android
x.y" rather than "toybox x.y.z on Android" anyway. my only concern was
that Android versions should be recognizably distinct from regular
ones so that anyone who shows up here with an Android-specific problem
is easily recognizable.

 -e

 1429418040.0