Age | Commit message (Collapse) | Author |
|
Test: none
Change-Id: I75c443e05f2b1e17fcb6823182717d2e6f5df7c4
|
|
We can call directly into the blueprint bootstrap.bash using values that
soong_ui has already calculated.
Instead of calling into blueprint.bash, build minibp with microfactory,
and directly run ninja. This allows us to get individual tracing data
from each component.
Test: m -j blueprint_tools
Test: m clean; m -j blueprint_tools
Change-Id: I2239943c9a8a3ad6e1a40fa0dc914421f4b5202c
|
|
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
|
|
Bug: 63720725
Test: m -j nothing
Test: mkdir o; ../bootstrap.bash; ./soong
Change-Id: Id1f8312678f36afd08b49f8511fec3e6e5ba8de2
|
|
Change-Id: Icdff44a54d14ddfc2266d99cf0578a8105716918
|
|
If BUILDDIR is a local symlink to another directory in the same parent
directory (out -> out.angler), then using out and .. as relative paths
to get back and forth work.
But if BUILDDIR is a symlink to another directory altogether (out ->
/mnt/sdd/out.master), then we shouldn't be relying on relative paths (so
that the source directory can still be moved).
Change-Id: I946c8116090410ab2b935eafba9b6e96f5f2f1dd
|
|
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
|
|
Change-Id: If40489d74136af4d15d4ff26210a50975a462497
|
|
Change-Id: I8182e57105b1c17254e082f6b72d2504befb7870
|
|
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
|
|
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
|
|
This creates the infrastructure that will be used to bootstrap the
soong primary builder through blueprint and ninja.
Change-Id: Iebed8f369e4db41b207d0b2a48a7a54a4dd7d45d
|