On Sat, Apr 18, 2015 at 4:59 PM, enh <[email protected]> wrote: > On Fri, Apr 17, 2015 at 12:47 AM, Rob Landley <[email protected]> wrote: >> On Wed, Apr 15, 2015 at 12:51 PM, enh <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
