bug#44544: Failures Building in non-Git Directory

[Jacob Bachmeyer]

Fred Wright wrote:
> When running in a directory that's not a git repo, there are at least 
> two failures:
>
> [...]
>
> Note that the allegedly "fatal" error doesn't avoid a zero exit status 
> (which may be a separate bug).

The "fatal" error is from Git, which exits reporting failure, which 
configure ignores.

> After the "successful" configure, building succeeds, with no error 
> messages:
>
> MacPro:dejagnu fw$ make
> [...]
>     rm -rf $backupdir; exit $rc
> Done. Now run 'make install'.
> MacPro:dejagnu fw$ echo $?
> 0
>
> Many tests now fail, which may or may not be related, so that's not 
> included here.

There seem to be other issues with Mac OS X; you are correct that those 
are a separate bug.

> But install fails:
>
> MacPro:dejagnu fw$ sudo make install
> Password:
> Done. Now run 'make install'.
> [...]
> make  install-data-hook
> revision=`cd . &&  git rev-parse --short HEAD` \
>     && sed -i -e "s/^set *frame_version.*/set frame_version 
> -${revision}/" /usr/local/share/dejagnu/runtest.exp
> fatal: not a git repository (or any parent up to mount point /Volumes)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not 
> set).
> make[2]: *** [install-data-hook] Error 128
> make[1]: *** [install-data-am] Error 2
> make: *** [install-am] Error 2
> MacPro:dejagnu fw$ echo $?
> 2

Same error here, but make does not ignore it.

> This is commonly seen when copying all tracked files to another 
> location for testing (e.g., using git ls-files and rsync), but for 
> purposes of reproducing the failure, another approach is to 
> temporarily rename the .git subdirectory to something else.

The issue was verified here using `git ls-files -z | cpio -0dp 
/tmp/some/where/else`.

> The above examples are from the current master branch @3d62df2.  They 
> are from Mac OSX, but essentially identical failures also occur on 
> Ubuntu 14.04, CentOS 7, and Fedora 25.
>
> These failures do not occur with the 1.6.2 release version, which may 
> be due to a new bug, or may be due to differences between release and 
> non-release builds.  In general, anything relying on git during builds 
> should have a fallback for the non-git environment.

The version hook was removed in commit 
650af6e75776a52afa4803d02aae0f923a9ec82f which is now current master.  
This should fix the problem.  Can you confirm that it corrects this issue?


-- Jacob