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
_______________________________________________
Bug-dejagnu mailing list
Bug-dejagnu@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-dejagnu
