Hi Eric, Thanks for the push!
On 2012-12-31 23:45, Eric Blake wrote: > On 12/28/2012 03:13 PM, Peter Rosin wrote: >> When building in a git checkout, but from a system lacking git, it >> is useful to fall back to the version determined when the git >> checkout was last used from a system sporting git. >> >> * build-aux/git-version-gen: Add support for the new option --fallback, >> which comes into play when there is no $tarball_version_file and >> git is not working. > > You didn't really document how to wire up makefiles to properly inject a I wanted to keep the patch small to evade the copyright assignment process from stalling the changes. > decent --fallback option into the script; but I'm at least satisfied > that this patch in isolation doesn't break existing packages that don't > use the --falback option, while leaving the door open for packages that > DO want to support the use of --fallback. > > As I understand it, the idea is that you have a shared folder that can > be accessed via multiple machines; on some machines, you have git, and > can therefore do a git checkout that populates Makefile with the right > information for use as a fallback. On other machines you lack git but > can see the .git directory in the shared directory; since it is still a > development build and you never ran 'make dist', you still want to have > the effect of a devel checkout, rather than building from a tarball, and > if all that git was needed for can be injected from the machine that has > git installed, then the other machine can benefit from the --falback. Right. (one nit though, it might be the same machine that accesses the shared folder through different means, Cygwin vs MSYS in my case, where Cygwin has git, but not MSYS) > I just now noticed v5, so I'll check that out before pushing anything. Good thing that. > I will point out that your script introduces yet another instance of a > non-portable construct: > > test -z "$fallback" > > Per the Autoconf manual: > > Posix also says that `test ! "STRING"', `test -n "STRING"' and > `test -z "STRING"' work with any string, but many shells (such as > Solaris, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4, etc.) get > confused if STRING looks like an operator: > > $ test -n = > test: argument expected > $ test ! -n > test: argument expected > $ test -z ")"; echo $? > 0 Sigh... > However, this idiom is already in use elsewhere in git-version-gen, so > it should be fixed in an independent patch. Thanks for tidying up! And for the record, I have now fixed the Libtool "regression" using this new support. Cheers, Peter
