goinstall (or gomake) feature request

[Tarmigan]

Could goinstall find the git/hg/svn version number for downloaded
packages and make it available to cmds or pkgs?

Currently I have a custom makefile rule as a pre-compile step to
create a version.go file that has something like `version = "123456"`.
I would like to switch to using goinstall instead of make for some
commands.

Wanting to include version information could be common for other
people, so could goinstall be taught that step or would it be too much
magic? It might only perform that step if there is an empty file
called "version.go". Or would this logic be a better fit for gomake
or the standard Makefiles?

Thoughts?

Thanks,
Tarmigan

[Kyle Lemons]

I would also be interested in making use of information which is baked into an executable.  I wonder, however, if there isn't a better way to do this than to generate a file and compile that in (which is my current approach).  While I don't necessarily think we should add versioning or build information to the "runtime" package, it might be interesting to consider adding a "var Watermark map[string]string" or something to the runtime package which would allow arbitrary strings to be embedded into the executable by 6l/gold.  Then builders like gomake could add things like compile date, user, vcs revision, etc into the executable and the runtime would make it available to client code.

(If you were embedding anything in there that you didn't want anyone with a hex editor to be able to change, you'd want to find some way to sign it to prevent tampering, I don't think baked-in build information really falls into that category, though, as it can be forged in any number of other ways.)

Just a thought,

~K

[Andrew Gerrand]

What do you use the version number for?

A suggestion: rather than foisting this complexity onto goinstall, you
could use a pre-commit hook with your VCS to increment a version
counter in the code. That way you guarantee the version number is
intact and correct, even if you distribute the code outside the VCS
(as a tarball, for example).

Andrew

[Tarmigan]

On Mon, Jul 18, 2011 at 4:40 PM, Andrew Gerrand <a...@golang.org> wrote:
> What do you use the version number for?

Just to identify (for debugging and support purposes) which version of
code someone is running if they have issues. Just like '8g -V'. So,
to address Kyle's point, it doesn't have security implications.

> A suggestion: rather than foisting this complexity onto goinstall, you
> could use a pre-commit hook with your VCS to increment a version
> counter in the code. That way you guarantee the version number is
> intact and correct, even if you distribute the code outside the VCS
> (as a tarball, for example).

It has those advantages, but doesn't work as well with distributed
development (both because of overlapping numbers and because hooks are
not propagated with new clones) or with branches (which are more
common in git than hg or svn). Another minor disadvantage for my use
is that the version info is a natural index into the VCS repository
whereas finding the version number from an incrementing number is an
extra step. Thanks for the suggestion: it may still work for me.

Thanks,
Tarmigan

[Tarmigan]

On Mon, Jul 18, 2011 at 10:17 AM, Kyle Lemons <kev...@google.com> wrote:
>  While I don't necessarily think we should add versioning or build
> information to the "runtime" package, it might be interesting to consider
> adding a "var Watermark map[string]string" or something to the runtime
> package which would allow arbitrary strings to be embedded into the
> executable by 6l/gold.  Then builders like gomake could add things like
> compile date, user, vcs revision, etc into the executable and the runtime
> would make it available to client code.

I like that idea. Would there be any complication at link time from
multiple packages wanting to add (hopefully identical) information
with the same keys (if a subpackage gets imported through two
different top-level packages)?

> (If you were embedding anything in there that you didn't want anyone with a
> hex editor to be able to change, you'd want to find some way to sign it to
> prevent tampering, I don't think baked-in build information really falls
> into that category, though, as it can be forged in any number of other
> ways.)

Yeah, it's just for debugging and support. Like '8g -V'.

Thanks,
Tarm

[Kyle Lemons]

I like that idea.  Would there be any complication at link time from
multiple packages wanting to add (hopefully identical) information
with the same keys (if a subpackage gets imported through two
different top-level packages)?

IANAcompilerdev, but I suspect that it would be something that 6l/gold bakes in at the final link when it makes an executable.  I'd imagine it would just ignore it if it were run in any other mode.  I think any application in which you need more detailed information about the versions of each library would want to be rolling its own mechanism anyway, but it could still bake it into the executable by providing the same arguments to the linker.