#!/usr/bin/env bash

# Bazel calls into this script, setting `BAZEL_REAL` to the location of
# the "actual" Bazel binary, expecting this script to call into Bazel
# appropriately. We output a helpful error message as suggested in
# https://github.com/bazelbuild/bazelisk#ensuring-that-your-developers-use-bazelisk-rather-than-bazel

if [[ -z "${BAZELISK_SKIP_WRAPPER}" ]] && [[ -z "${SHUT_UP_ABOUT_BAZELISK}" ]]
then
    echo "You're not using Bazelisk! Your build may fail due to a mismatched" >&2
    echo "Bazel version. Using Bazelisk is recommended." >&2
    echo "On macOS, you can install Bazelisk with:" >&2
    echo "    brew uninstall bazel; brew install bazelisk" >&2
fi


# Sometimes developers don't like needing to run gazelle on their own. If they
# set up this environment variable, we'll run it for them before executing
# whatever command they wanted.
#
# In theory there might be better options than this, but they aren't obvious.
# One thing you might consider is autogazelle, but it has two severe problems:
#  * It always watches everything in the entire project directory, which
#    can be way too many things. This one is relatively easy to fix.
#  * It always passes --index=false. This one you might thing you can fix by
#    just changing it to not pass that setting, but then you run into the
#    problem that building that index is where most of the time gets spent
#    anyway.
#
# Another approach might be to try to run gazelle when the imports change.
# Unfortunately, it's not obvious how to do that well. One thought might be
# to hook goimports or crlfmt up to either run gazelle or talk to some
# daemon which might run gazelle. However, GoLand manages the imports for most
# folks these days without importing such a tool. I could not find a hook to
# have GoLand trigger some action. Maybe this approach has legs if only we tell
# folks to disable the GoLand feature.
#
# Another approach might be to have a daemon watch for filesystem changes and
# then run gazelle whenever they happen. This might get really annoying, so
# you might want to rate limit how frequently it will run. If you do that,
# it'll be frustrating when you go to run your test and it hasn't generated
# yet. It'll also burn a bunch of cycles just constantly running.
#
# Another approach might be to look at the git diff and see if anything in an
# import block has changed. This one seems plausible. You could probably write
# a reasonably simple tool which loads the relevant files, looks at the line
# ranges that changed and see if they fall in an import block.
if [[ -n "${ALWAYS_RUN_GAZELLE}" ]]; then
    case "${1:-}" in
    build|test)
        "$BAZEL_REAL" run //:gazelle
        echo "done running gazelle" 1>&2
        ;;
    esac
fi

# If output base is not set yet, try picking one if enabled and available.
source "$(dirname "${0}")/claim_output_base.sh"

# If something picked an output base for us, use it.
if  [ ! -z "${BAZEL_OUTPUT_BASE-}" ]; then
  $BAZEL_REAL --output_base="${BAZEL_OUTPUT_BASE}" "$@"
else
  $BAZEL_REAL "$@"
fi

