Re: Feature request

[Rich Felker <dalias@aerifal.cx>]

On Tue, Oct 29, 2013 at 08:23:43PM +0100, Szabolcs Nagy wrote:
> * Kurt H Maier <khm@sciops.net> [2013-10-29 18:53:38 +0000]:
> > Quoting Andrew Bradford <andrew@bradfordembedded.com>:
> > >How often is this a concern?
> > >How are people obtaining non-release source trees not via an scm tool?
> > >
> > 
> > By pulling on one machine and copying it to various build hosts.  The
> > fewer build dependencies, the better.
> > 
> 
> or building in a chroot
> or in qemu from a v9fs mount
> ...
> 
> the build should not fail if git is unavailable

Exactly.

> otherwise the version string is not critical in that case
> (if it's a make variable then it can be overridden from
> config.mak or from the make cmdline anyway)

It's not _critical_, but if it's horribly wrong, that defeats the
purpose of being able to determine the version installed. Perhaps a
good fallback approach would be:

1. Have a version file which always contains the most recent released
   version (i.e. it's updated in the tagged commit for the release).

2. At build time, if git is available and .git exists, use git
   describe to construct the version string.

3. Otherwise, use the version file (from #1 above), and if .git
   exists, append -unknown-git or similar to it so that it's clear
   that there may be changes beyond what was in the release.

Clearly the version string should make it into the dynamic linker's
usage output, but is there anywhere else it should be visible (such as
a string in static binaries, or a confstr() string)? I don't want to
go adding bloat that makes users mad, but it also may be frustrating
not to know what version a binary was linked with, so I think this is
a question that merits some discussion.

Rich