This way we only have one way to start a build, which always has logging
/ tracing / etc, even if we don't need Kati.
There's two ways to use this:
As a direct replacement for mkdir out; cd out; ../bootstrap.bash;
./soong -- as long as --skip-make is always passed, we'll never run
Kati, and Soong will run outside of it's "make" mode. This preserves
most of the speed, and allows full user control over the Soong
configuration.
A (experimental, dangerous) way to temporarily bypass the product
variable and kati steps of a build. As long as a user is sure that
nothing has changed from the last build, and they know exactly which
Ninja targets they want to build (which may not be the same as the
arguments normally passed to 'm'), this can lead to shorter build
startup times.
Test: rm -rf out; m --skip-make libc
Test: rm -rf out; m libc; m --skip-make libc
Test: rm -rf out; mkdir out; cd out; ../bootstrap.bash; ./soong libc
Test: build/soong/scripts/build-ndk-prebuilts.sh
Change-Id: Ic0f91167b5779dba3f248a379fbaac67a75a946e
ninja has been moved from prebuilts/ninja to prebuilts/build-tools so it
can share the hermetic libc++.so there.
Change-Id: I0b6e76baaa6916a8c7fd19c684b792ccef2f9cb1
The existing behavior of using the build directory as the working
directory is useful if you want to move/copy the output directory around
and SRCDIR still refers the the source. But, it's more useful to have
the source directory be the working directory. Tools like cpp(__FILE__)
and other debug prints embed relative paths from the working directory.
We also have tools that expect the working directory to be $TOP.
Change-Id: Ia0f1d3c6b7df72d61cf5628efa2baa98bd19775b
Using a path with a space to execute soong is unlikely, but it
might as well work. Quote all the paths in the soong scripts.
Soong and blueprint will still both fail if the relative path between
the soong script and the source directory has a space in it, but this
is even more unlikely.
Change-Id: I8986f10115209d69b09b82ffea26e4b10d29c197
Ninja can't depend on environment variables, so modifying build
behavior based on environment variables requires coordinating
between the soong script that invokes ninja and the soong_build
manifest generator.
Allow any module to call Config.Getenv to get the contents of an
environment variable while registering a dependency on it.
After all modules have been processed write out the state of
all used environment variables to a JSON file called
.soong.environment. During the next build the soong script
will use the soong_env tool to compare the contents of
.soong.environment to the current environment, and force a
build manifest regeneration by deleting the .soong.environment
file if any variables have changed.
Change-Id: Id0d81933a857bc2fc1cd7a393a3c6cec73dc4824
bootstrap.bash creates a soong script in the output directory using
build/soong/soong.in. This requires a manual rebootstrap any time
soong.in changes. Instead, have bootstrap.bash symlink
build/soong/soong.bash to soong in the output directory, and create
a file called .soong.bootstrap in the output directory that contains
the variables that bootstrap.bash sets.
Change-Id: I5e6e54c2e8bdde876941e2e082f9ba177c757cbf
Dan Willemsen