ab223a512b
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
23 lines
843 B
Text
23 lines
843 B
Text
# Included by .minibootstrap/build.ninja, which is written by bootstrap.bash
|
|
#
|
|
# Expected input variables:
|
|
# topFile - The path to the top-level Blueprints(etc) file
|
|
# extraArgs - Any extra arguments to pass to minibp (-t)
|
|
# bootstrapBuildDir - The path to the build directory
|
|
|
|
ninja_required_version = 1.7.0
|
|
|
|
myGlobs = ${bootstrapBuildDir}/.minibootstrap/build-globs.ninja
|
|
subninja ${myGlobs}
|
|
|
|
rule build.ninja
|
|
command = ${builder} ${extraArgs} -b ${bootstrapBuildDir} -n ${builddir} -d ${out}.d -globFile ${myGlobs} -o ${out} ${in}
|
|
deps = gcc
|
|
depfile = ${out}.d
|
|
description = ${builder} ${out}
|
|
|
|
bootstrapNinja = ${bootstrapBuildDir}/.bootstrap/build.ninja
|
|
|
|
build ${bootstrapNinja}: build.ninja ${topFile} | ${builder}
|
|
builder = ${bootstrapBuildDir}/.minibootstrap/minibp
|
|
default ${bootstrapNinja}
|