2014-05-28 01:34:41 +02:00
|
|
|
#!/bin/bash
|
|
|
|
|
2014-06-14 01:25:09 +02:00
|
|
|
# This script serves two purposes. First, it can bootstrap the standalone
|
|
|
|
# Blueprint to generate the minibp binary. To do this simply run the script
|
|
|
|
# with no arguments from the desired build directory.
|
|
|
|
#
|
|
|
|
# It can also be invoked from another script to bootstrap a custom Blueprint-
|
|
|
|
# based build system. To do this, the invoking script must first set some or
|
|
|
|
# all of the following environment variables, which are documented below where
|
|
|
|
# their default values are set:
|
|
|
|
#
|
|
|
|
# BOOTSTRAP
|
2015-12-10 03:03:13 +01:00
|
|
|
# WRAPPER
|
2014-06-14 01:25:09 +02:00
|
|
|
# SRCDIR
|
2017-07-19 04:37:37 +02:00
|
|
|
# BLUEPRINTDIR
|
2015-07-14 03:11:49 +02:00
|
|
|
# BUILDDIR
|
2017-07-20 07:43:30 +02:00
|
|
|
# NINJA_BUILDDIR
|
2014-06-14 01:25:09 +02:00
|
|
|
# GOROOT
|
|
|
|
#
|
|
|
|
# The invoking script should then run this script, passing along all of its
|
|
|
|
# command line arguments.
|
|
|
|
|
|
|
|
set -e
|
|
|
|
|
2015-06-24 02:21:00 +02:00
|
|
|
EXTRA_ARGS=""
|
|
|
|
|
2014-06-14 01:25:09 +02:00
|
|
|
# BOOTSTRAP should be set to the path of the bootstrap script. It can be
|
|
|
|
# either an absolute path or one relative to the build directory (which of
|
|
|
|
# these is used should probably match what's used for SRCDIR).
|
2015-12-10 03:03:13 +01:00
|
|
|
if [ -z "$BOOTSTRAP" ]; then
|
|
|
|
BOOTSTRAP="${BASH_SOURCE[0]}"
|
|
|
|
|
|
|
|
# WRAPPER should only be set if you want a ninja wrapper script to be
|
|
|
|
# installed into the builddir. It is set to blueprint's blueprint.bash
|
|
|
|
# only if BOOTSTRAP and WRAPPER are unset.
|
|
|
|
[ -z "$WRAPPER" ] && WRAPPER="`dirname "${BOOTSTRAP}"`/blueprint.bash"
|
|
|
|
fi
|
2014-06-14 01:25:09 +02:00
|
|
|
|
2014-05-28 01:34:41 +02:00
|
|
|
# SRCDIR should be set to the path of the root source directory. It can be
|
|
|
|
# either an absolute path or a path relative to the build directory. Whether
|
2014-06-14 01:25:09 +02:00
|
|
|
# its an absolute or relative path determines whether the build directory can
|
|
|
|
# be moved relative to or along with the source directory without re-running
|
|
|
|
# the bootstrap script.
|
|
|
|
[ -z "$SRCDIR" ] && SRCDIR=`dirname "${BOOTSTRAP}"`
|
|
|
|
|
2017-07-19 04:37:37 +02:00
|
|
|
# BLUEPRINTDIR should be set to the path to the blueprint source. It generally
|
|
|
|
# should start with SRCDIR.
|
|
|
|
[ -z "$BLUEPRINTDIR" ] && BLUEPRINTDIR="${SRCDIR}"
|
|
|
|
|
2015-07-14 03:11:49 +02:00
|
|
|
# BUILDDIR should be set to the path to store build results. By default, this
|
|
|
|
# is the current directory, but it may be set to an absolute or relative path.
|
|
|
|
[ -z "$BUILDDIR" ] && BUILDDIR=.
|
|
|
|
|
2017-07-20 07:43:30 +02:00
|
|
|
# NINJA_BUILDDIR should be set to the path to store the .ninja_log/.ninja_deps
|
|
|
|
# files. By default this is the same as $BUILDDIR.
|
|
|
|
[ -z "$NINJA_BUILDDIR" ] && NINJA_BUILDDIR="${BUILDDIR}"
|
|
|
|
|
2015-06-11 01:55:02 +02:00
|
|
|
# TOPNAME should be set to the name of the top-level Blueprints file
|
|
|
|
[ -z "$TOPNAME" ] && TOPNAME="Blueprints"
|
|
|
|
|
2014-06-14 01:25:09 +02:00
|
|
|
# These variables should be set by auto-detecting or knowing a priori the host
|
|
|
|
# Go toolchain properties.
|
|
|
|
[ -z "$GOROOT" ] && GOROOT=`go env GOROOT`
|
|
|
|
|
|
|
|
usage() {
|
|
|
|
echo "Usage of ${BOOTSTRAP}:"
|
|
|
|
echo " -h: print a help message and exit"
|
2017-07-19 04:37:37 +02:00
|
|
|
echo " -b <builddir>: set the build directory"
|
|
|
|
echo " -t: run tests"
|
2020-07-09 23:24:56 +02:00
|
|
|
echo " -n: use validations to depend on tests"
|
2014-06-14 01:25:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
# Parse the command line flags.
|
2020-07-09 23:24:56 +02:00
|
|
|
while getopts ":b:hnt" opt; do
|
2014-06-14 01:25:09 +02:00
|
|
|
case $opt in
|
2015-07-14 03:11:49 +02:00
|
|
|
b) BUILDDIR="$OPTARG";;
|
2020-07-09 23:24:56 +02:00
|
|
|
n) USE_VALIDATIONS=true;;
|
2017-08-10 00:13:12 +02:00
|
|
|
t) RUN_TESTS=true;;
|
2014-06-14 01:25:09 +02:00
|
|
|
h)
|
|
|
|
usage
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
\?)
|
|
|
|
echo "Invalid option: -$OPTARG" >&2
|
|
|
|
usage
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
:)
|
|
|
|
echo "Option -$OPTARG requires an argument." >&2
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2017-08-10 00:13:12 +02:00
|
|
|
# If RUN_TESTS is set, behave like -t was passed in as an option.
|
|
|
|
[ ! -z "$RUN_TESTS" ] && EXTRA_ARGS="${EXTRA_ARGS} -t"
|
|
|
|
|
2020-07-09 23:24:56 +02:00
|
|
|
# If $USE_VALIDATIONS is set, pass --use-validations.
|
|
|
|
[ ! -z "$USE_VALIDATIONS" ] && EXTRA_ARGS="${EXTRA_ARGS} --use-validations"
|
|
|
|
|
2018-10-26 07:02:10 +02:00
|
|
|
# If EMPTY_NINJA_FILE is set, have the primary build write out a 0-byte ninja
|
|
|
|
# file instead of a full length one. Useful if you don't plan on executing the
|
|
|
|
# build, but want to verify the primary builder execution.
|
|
|
|
[ ! -z "$EMPTY_NINJA_FILE" ] && EXTRA_ARGS="${EXTRA_ARGS} --empty-ninja-file"
|
|
|
|
|
2017-08-10 00:13:12 +02:00
|
|
|
# Allow the caller to pass in a list of module files
|
|
|
|
if [ -z "${BLUEPRINT_LIST_FILE}" ]; then
|
|
|
|
BLUEPRINT_LIST_FILE="${BUILDDIR}/.bootstrap/bplist"
|
|
|
|
fi
|
|
|
|
EXTRA_ARGS="${EXTRA_ARGS} -l ${BLUEPRINT_LIST_FILE}"
|
|
|
|
|
Simplify bootstrap
tl;dr: Read if you don't use the wrapper or use SKIP_NINJA
Previously, we were relying on the ninja behavior of restarting the
build when the build.ninja file was updated to switch between different
bootstrap stages. But that means that every step that could produce a
build.ninja must pass in order to switch to a different stage. That
wasn't a big problem when we had a two stage build -- there was very
little that could fail in the second stage before we chose to go back to
the first stage. But when we had a three stage build, it was possible to
get into a state (usually during development) where you were in the
second stage, but the build was failing because the first stage needed
to be run. This was fixed in d79f1af7423e0ef7a13573efdae5100a57fabc82
by adding a wrapper that always started building at the first stage.
But this kept all of the complexity of using ninja restarts without any
of the benefits, so this change removes that complexity and just runs
each stage sequentially in the wrapper. So the wrapper is now required.
Since we're no longer going through choosestage, we can also skip the
template parsing for the later stages that don't need to be templated --
this can save a couple of seconds for large files.
In addition to all of the above, this also lets Soong reduce the number
of times the main ninja file is loaded. We had been running the wrapper
once (3 stages), then running ninja again after combining the
Soong-generated build.ninja with the Kati-generated build.ninja. This
change lets us removing the intermediate parsing of Soong's build.ninja,
so that we only execute ninja 3 times per build. It also lets us have
dependencies on pools or rules from Kati in the primary builder, since
we're never executing the main build.ninja without the Kati build.ninja.
The wrapper has a new option, NINJA to provide the path to ninja. This
used to be hardcoded to `ninja`, and will still default to that. But
we'll be running the first two bootstrap stages with $NINJA even if
SKIP_NINJA is set.
The wrapper passes "-w dupbuild=err" to ninja now -- this really should
always be turned on if you care about reliable builds.
Change-Id: I6f656b74eb3d064b8b9e69d1d6dac1129d72b747
2016-08-13 21:42:11 +02:00
|
|
|
mkdir -p $BUILDDIR/.minibootstrap
|
2015-07-14 03:11:49 +02:00
|
|
|
|
2017-07-19 04:37:37 +02:00
|
|
|
echo "bootstrapBuildDir = $BUILDDIR" > $BUILDDIR/.minibootstrap/build.ninja
|
|
|
|
echo "topFile = $SRCDIR/$TOPNAME" >> $BUILDDIR/.minibootstrap/build.ninja
|
|
|
|
echo "extraArgs = $EXTRA_ARGS" >> $BUILDDIR/.minibootstrap/build.ninja
|
2017-07-20 07:43:30 +02:00
|
|
|
echo "builddir = $NINJA_BUILDDIR" >> $BUILDDIR/.minibootstrap/build.ninja
|
2017-07-19 04:37:37 +02:00
|
|
|
echo "include $BLUEPRINTDIR/bootstrap/build.ninja" >> $BUILDDIR/.minibootstrap/build.ninja
|
|
|
|
|
Run globs during earlier bootstrap phases
Instead of sometimes re-running minibp/the primary builder during the
next phase, run bpglob earlier to check dependencies.
We've run into issues where the environment is slightly different
between bootstrapping phase and the main build phase. It's also a
problem because our primary builder (Soong) exports information used by
another tool (Kati) that runs in between the bootstrapping phases and
the main phase. When Soong would run in the main phase, it could get out
of sync, and would require the build to be run again.
To do this, add a "subninja" include a build-globs.ninja file to each
build.ninja file. The first time, this will be an empty file, but we'll
always run minibp / the primary builder anyway. When the builder runs,
in addition to writing a dependency file, write out the
build-globs.ninja file with the rules to run bpglob.
Since bpglob may need to be run very early, before it would normally be
built, build it with microfactory.
Change-Id: I89fcd849a8729e892f163d40060ab90b5d4dfa5d
2018-07-06 06:56:59 +02:00
|
|
|
if [ ! -f "$BUILDDIR/.minibootstrap/build-globs.ninja" ]; then
|
|
|
|
touch "$BUILDDIR/.minibootstrap/build-globs.ninja"
|
|
|
|
fi
|
|
|
|
|
2017-08-10 00:13:12 +02:00
|
|
|
echo "BLUEPRINT_BOOTSTRAP_VERSION=2" > $BUILDDIR/.blueprint.bootstrap
|
2017-07-19 04:37:37 +02:00
|
|
|
echo "SRCDIR=\"${SRCDIR}\"" >> $BUILDDIR/.blueprint.bootstrap
|
|
|
|
echo "BLUEPRINTDIR=\"${BLUEPRINTDIR}\"" >> $BUILDDIR/.blueprint.bootstrap
|
2017-07-20 07:43:30 +02:00
|
|
|
echo "NINJA_BUILDDIR=\"${NINJA_BUILDDIR}\"" >> $BUILDDIR/.blueprint.bootstrap
|
2017-07-19 04:37:37 +02:00
|
|
|
echo "GOROOT=\"${GOROOT}\"" >> $BUILDDIR/.blueprint.bootstrap
|
2017-08-10 00:13:12 +02:00
|
|
|
echo "TOPNAME=\"${TOPNAME}\"" >> $BUILDDIR/.blueprint.bootstrap
|
|
|
|
|
|
|
|
touch "${BUILDDIR}/.out-dir"
|
2015-12-10 03:03:13 +01:00
|
|
|
|
|
|
|
if [ ! -z "$WRAPPER" ]; then
|
|
|
|
cp $WRAPPER $BUILDDIR/
|
|
|
|
fi
|