build: gen-version-i.sh: make it an error if git describe fails

build: gen-version-i.sh: make it an error if git describe fails

When doing `make` as a regular user, building from the git repo, the
src/common/version.i file may contain:

    #define BT_VERSION_GIT "v1.2.0-3717-ga7074326ba9a"

Then, doing `make` as root, when logged in with `su -`, generates a new
version.i with an empty version string:

    #define BT_VERSION_GIT ""

This is because the `git describe --tags --dirty --abbrev=12` command
fails with:

    make[1]: Entering directory '/home/smarchi/build/babeltrace/src/common'
      GEN      version.i
    fatal: detected dubious ownership in repository at '/home/smarchi/src/babeltrace'
    To add an exception for this directory, call:

            git config --global --add safe.directory /home/smarchi/src/babeltrace

By default, git refuses to work on a git repository owned by a different
user.  Note that running a command under sudo doesn't hit this problem,
because git honors the SUDO_UID & co variables.

I think that the current state is buggy, because it results in the
installed library having an empty version string, and it happens almost
silently.  I suggest making it an error if that `git describe` command
fails, since the script can't work correctly in those conditions.  The
user would then need to adjust their setup: either add the directory to
git's safe.directory variable (as the git command suggested) or run the
command under sudo.

Doing "make install" as root not under sudo is one use case, but another
one would be to do the complete build as a regular user from a source
git repository that is owned by another reguar user.  In that case, the
script wouldn't be able to generate a version string in the first
place.  I think that the right thing to do is to error out.  And in that
case, the only solution I see if or the user to use the git
safe.directory variable.

Note that the second git describe command is expected to fail in normal
situations, when it doesn't find an exact tag match, so the `|| true`
there is fine.

Change-Id: I879ddc2184223266829afceca252fe971795f395
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Fixes: https://bugs.lttng.org/issues/1376
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10104
Tested-by: jenkins <jenkins@lttng.org>