This effectively moves execution of Bazel actions outside of soong_build
and alongside ninja execution of the actual ninja files, whether that be
by ninja or by Bazel itself.
This almost allows for mixed builds and Bazel-as-Ninja-executor to
coexist, but requires hacks explained in b/175307058.
Test: Treehugger
Test: lunch aosp_flame && USE_BAZEL_ANALYSIS=1 m libc
Test: lunch aosp_flame && USE_BAZEL=1 USE_BAZEL_ANALYSIS=1 m libc,
though this requires a hack of the main BUILD file. See b/175307058
Change-Id: Ia2f6b0f1057e8cea3809de66d8287f13d84b510c
When a shared library providing stubs is included in an APEX, only the
stub variant (i.e. version:"1", etc.) gets emitted to Android.mk. This
enforces that everything in the Make world to link to the stub providing
only the public APIs of the library. The non-stub variant (i.e.
version:"") isn't exposed, otherwise, others will be able to access
private part of the lib which isn't guaranteed to be stable.
This has been done by unhiding the stub variant when it is known that
the library is actually included in an APEX. Note that stub variants are
by default hidden.
The above mechanism however doesn't work when the shared library is
replaced by a prebuilt and when the APEX is also replaced by a prebuilt.
Then, the fact that the prebuilt library is actually in the APEX gets
lost. In that case, AnyVariantDirectlyInAnyApex() returns false for the
prebuilt library. As a result, the stub variant remains hidden and not
emitted to Android.mk.
This change fixes the problem by checking if the lib isn't available for
the platform at all. If not available for the platform (e.g.
apex_available doesn't have "//apex_available:platform"), the lib is
assumed to be included in an APEX even when it actually didn't go
through the apex mutator (... because it's a prebuilt).
Bug: 175166063
Test: m nothing
Change-Id: I41fabd5b368baecf4dc3c5a080b466f8bcd79d77
Bazel is executed several times during the execution of soong_build.
For each bazel execution, generate a profile and save under the
BAZEL_METRICS_DIR which is defined in soong_ui.
Bug: b/174479924
Test: * USE_BAZEL_ANALYSIS=1 USE_BAZEL=1 m nothing and checked
if the cquery and graph build bazel profiles were generated.
* Verified that the generated bazel profiles were uploaded
to the local dev metrics pipeline.
Change-Id: I3d20204484dc6c5a1525a5d3eec1d62cfb33535b
We had a dependency on each file in the asset directories, but that
wouldn't cause aapt2 to run if a file was removed. Add a dependency
on a file that contains the list of files in the asset directories.
Fixes: 172867096
Test: m CarrierConfig && rm packages/apps/CarrierConfig/assets/carrier_config_no_sim.xml && m CarrierConfig
Change-Id: I35f3b85355fa890a3e95eaa6458a21466b6930e4
Add PackageFile that creates a PackageSpec like InstallFile,
but doesn't create the install rule. Also improve the documentation
on InstallFile and friends, and on HostToolProvider.
Bug: 124313442
Test: m checkbuild
Change-Id: I30f44a2b3833e48d0bb71bf7c45955f88fb00bc8
Generally ...DepsMutator methods add dependencies between modules but
the apexDepsMutator does not which can be confusing. This renames
apexDepsMutator to apexInfoMutator and adds some extra documentation to
clarify its function. It also renames the registered name for the
mutator and its associated providers from apex_deps to apex_info.
Test: m nothing
Bug: 171061220
Change-Id: Ic074a281215b23e982448ccff7ac075236123bee
This fix a bug in a recent android_app_import-related change
(I8215aa1a6dad74b503eaa1169a64f8c30dda287c) where it uses an incorrect
module reference, and so disables a prebuilt module if its source-based
counterpart is disabled.
Test: app_test.go
Bug: 152343232
Change-Id: Ic7f5ca40be58f06e44b5ec4945caf209ef2dae96
1. Soong can now detect PRODUCT_COMPRESSED_APEX flag
We don't want APEX to be compressed on all devices. Only those that
have explicitely set PRODUCT_COMPRESSED_APEX flag.
2. Handle "compressible" field in soong build rule
On devices that supports APEX compression, all APEX will be
compressed by default. If any apex does not want to be compressed,
they will need to state that by setting "compressible" field to
false
3. Can use apex_compression_tool to compress APEX
Note we compress the APEX after it has been signed. That way, when
we decompress we will get a signed APEX.
4. Place the compressed APEX in system with .capex extension
This makes it easy to identify. We still preserve the original
extension so that when we decompress, we can just rename by cuttif
off the .capex extension.
Note: with this change, we can create a system image with compressed
APEX, but we cannot boot with it since platform doesn't know how to
handle .capex files. Platform support will be added on follow up CLs.
Bug: 172911362
Test: OVERRIDE_PRODUCT_COMPRESSED_APEX=true m (apex_test.go)
Test: observed $OUT/system/apex has .capex files
Change-Id: I20ac4c4ceb521924c751a6017f979b2d808fdded
Add TransitivePackagingSpecs to return the PackagingSpecs for a
module and any of its transitive dependencies that have dependency
tags for which IsInstallDepNeeded returns true.
Bug: 124313442
Test: m checkbuild
Change-Id: I1d6750db830d1601d696349674f0b7071372ca11
Implement depSet as a generic depsets implementation using reflection,
and then make DepSet a type-safe wrapper around it. This will allow
additional wrappers for depsets that work with other types. All of
this can be replaced with generics once Go supports them.
Test: depset_test.go
Change-Id: Id9df17bcc76f6c1545e7eb498f298066cf8a7679
Export files to install through a depset instead of a list to reduce
the size at each module.
Bug: 124313442
Test: m checkbuild
Change-Id: I6a51c89acc9f0f3a9c3c792d3ef8a7cfd6b8bef2
I added in case anyone needs to access AndroidMkEntries to generate
footer lines, but nobody uses it, and it only confuses people.
Test: m nothing, TreeHugger
Change-Id: Ic8a450e3c306d9228c1fdec212c7441bd6aaee03
This fixes a bug where android_app_import or android_test_import without
a matching variant or a default apk property value breaks the build.
Test: app_test.go
Fixes: 152343232
Change-Id: I8215aa1a6dad74b503eaa1169a64f8c30dda287c
This CL adds a new CONVERT_TO_BAZEL env var, and a bp2build goal. It
reuses the queryview architecture, but registers no mutators before
converting to BUILD files. This gives us a blank slate of the module
graph to work with, and create a shadow/alternate pipeline of mutators
to converge the Bazel BUILD graph to be semantically equivalent with the
Android.bp graph (after apply its current set of mutators).
The command to do so is:
$ CONVERT_TO_BAZEL=true m bp2build
To not clobber with queryview, the generated files are in
out/soong/bp2build.
Test: CONVERT_TO_BAZEL=true m bp2build && bazel query --config=bp2build //...
Test: m queryview && bazel query --config=queryview //..
Test: soong tests
Test: TH presubmit
Fixes: 174465461
Signed-off-by: Jingwen Chen <jingwen@google.com>
Change-Id: I4dd0ccc73abc345d70a50ca2803d6f400cd8c863
Previously, the vendor_ramdisk variant of a module installs the
init.rc file to /vendor/etc/init.
In first stage init, no init rc files are read, so no init rc files
should be installed to any ramdisks.
This change removes LOCAL_INIT_RC for the (vendor_)ramdisk variant
of a module, so that init rc file is not installed for (vendor_)ramdisk
variant of a module.
Test: m snapuserd snapuserd.vendor_ramdisk
and manually inspect the out directory
Fixes: 174587489
Change-Id: I71227d807244b6538be0d6acce5e94f129a86065
sbox.textproto files are created when handling genrule. The command
for the genrule and output files are written to this file in the
following format:
commands <
command: "...."
copy_after: <
from: "out/asm-generic/auxvec.h"
to: "out/soong/.intermediates/kernel/msm-4.19/qti_generate_kernel_headers_arm/gen/asm-generic/auxvec.h"
>
copy_after: <
from: "out/asm-generic/bitsperlong.h"
to:
"out/soong/.intermediates/kernel/msm-4.19/qti_generate_kernel_headers_arm/gen/asm-generic/bitsperlong.h"
>
....
>
This file grow by one copy_after entry for each output file.
When generating kenrnel headers where the number of output files are
~1000 we run into problems as the contents of sbox.textproto files
are written to disk by generating a shell script using the following
template: /bin/bash -c 'echo -e "$$0" > $out' $content
If $content is very long as in the case of generating kernel headers we
run into the issue where the command line is so long that the shell
script return E2BIG.
Fix this issue by chuking contents into smaller files and then merge
them as a final step.
Test: Build
Issue: 174444967
Change-Id: I1a74023b4222d19672e4df7edb19810a9cf2136f
Enable the RuleBuilder and RuleBuilderCommand methods to access
the BuilderContext by passing it to NewRuleBuilder instead of
RuleBuilder.Build.
Test: genrule_test.go
Test: rule_builder_test.go
Test: m checkbuild
Change-Id: I63e6597e19167393876dc2259d6f521363b7dabc
MTS is introducing partial MTS test suites that are per-module, with
names of the format: mts-${MODULE}. By centralizing the code for test
suites, we can automatically add "mts" test suite when an
"mts-${MODULE}" test suite is specified, reducing duplication.
Test: m mts
Bug: 170318013
Change-Id: I8ce9d3c252fcc0a937bb5f2826d21cb6c6932d82
aosp/1501613 has landed. The filtering hack is no longer needed.
Also, fixed a bug that the dependency to the dynamic linker is not
treated as install dep.
Bug: N/A
Test: `m hosttar` and compare the built cvd-host_package.tar.gz with and
without this change. There is no removed file.
Change-Id: I19ef64e10d34bc8be2592c5258505cd632c91af9
List of stub libraries from system (and bionic APEX) is currently
managed in static file. This change generates the list at build time and
adds to the system config so linkerconfig can use it.
Bug: 172889962
Test: Build cuttlefish and confirmed list is generated in
/system/etc/linker.config.pb
Change-Id: Ie0400e9d1098b0de19c6a7c25f261384aadde0a3
Previously, the dep tag used by PackagingBase was fixed, which prevented
some of its clients (e.g. cvd-host-package) from opting in to
android.InstallAlwaysNeededDependencyTag. Now, PackagingBase.AddDeps
accepts the dependency tag to use.
Also, dependencies toward rust dylib, rlib, and proc_macro are
configured to return true on InstallDepNeeded. This is required to
install shared_lib dependencies of the rust modules when they are
depended on by a rust binary.
Exempt-From-Owner-Approval: a trivial change after +2 from the owner.
This has to land ASAP as many users are affected by acloud being
unavailable.
Bug: N/A
Test: m
Test: acloud create --local-instance --local-image
Change-Id: If22aee7c6f314fcb03b9d4fe6901a2557f1e899c
This change adds some additional tests to cover the different
combinations of setting OutputFile and DistFiles properties in the
AndroidMkEntry.
These tests will prevent follow up changes from inadvertently changing
the behavior that some modules rely on.
Test: m nothing
Bug: 174226317
Change-Id: I6ab6f2711a5fa416ea2b84a1e0b8754d525d7a0c
Previously in order to make use of dist entries with tag properties it
was necessary for each module type to be modified to store the results
of GenerateTaggedDistFiles(module) in the AndroidMkEntry.DistFiles
property. This change generalizes that mechanism to work across all
module types.
This change does improve the behavior of a couple of tests where
previously a dist with tag property was ignored because tagged dist
files were not available now it is used correctly.
Some module types do not implement OutputFileProducer interface and so
they cannot handle dist with tag properties. This change makes it an
error to attempt to do that. That necessitated adding OutputFiles(tag)
method to customModule in queryview_test.go as some of the tests in
that file used dist entries with tag properties.
Follow up changes will remove the code that was made redundant by this.
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Bug: 174226317
Change-Id: Ifc54d67db10ce0d0fe8179c05b97a2be2113be4e
Previously, only the dist property's nested properties were checked for
correctness. This change also checks the dists property's nested dist
structures and adds some tests to verify that the checks are run and
correctly report the location of the incorrect property even when it is
within a slice of dist structs.
Test: m nothing
Bug: 174226317
Change-Id: If5a19360e1e4c98ee3b5afc813e35349d1fc6f6f
Change https://r.android.com/1335521 added tag property to the Dist
struct so that it could be used to select one of a number of different
output files to copy to the dist instead of the single file that the
module type made available for dist. The output files were selected
by passing the tag to OutputFiles(tag).
Module types that wanted to support this new approach had to explicitly
set AndroidMkEntries.DistFiles = GenerateTaggedDistFiles(module).
Unfortunately, doing that had a side effect of changing the behavior of
dist entries without a tag.
That was because the change treated a tag that was not specified, as
being the same as "". So, prior to the change no tag meant use the
default dist file but after it meant use the paths returned by
OutputFiles(""). That changed the behavior of the java.Library type
which affected the behavior of the android_app module type.
Prior to the change the java_library would make the
Library.outputFile available for dist when no tag was specified. After
that change it would make Library.outputFile plus
Library.extraOutputFiles. The latter is usually empty except for
android_app which adds some extra files into there which will now be
copied to the dist. That change may have been intentional but there
was no mention of it in the change or the bug. Even if it wasn't
intentional it may still be beneficial.
Any module type that wants to add support for tags in dist runs the
risk of introducing similar changes in behavior. This change
differentiates between the tag not being set and the tag being set to
"" to avoid that possibility and to make the default behavior
explicit for those module types that have switched.
It does so as follows:
* Adds a DefaultDistTag constant that is used when the tag is not set.
It is a string that is unlikely to be used as an actual tag as it
does not start with a . and uses some special characters.
* The DefaultDistTag is used in MakeDefaultDistFiles(paths) to indicate
that the supplied paths are the default ones and and also in
GenerateTaggedDistFiles() for Dist structures that have no tag
property set.
* The DefaultDistTag is passed to OutputFiles(tag) just in case the
module type has explicitly defined the paths to associate with that
tag in there. If it has then it overrides the legacy behavior. If it
has not then it is just ignored and falls back to using the previous
behavior.
* The java.Library.OutputFiles(tag) method explicitly handles the
DefaultDistTag and returns Library.outputFile for it which restores
the behavior from before the change that added dist.tag support.
* Similar change was made to apexBundle.OutputFiles(tag) in order to
preserve its previous behaviour.
* The customModule used by TestGetDistContributions has been modified
to also preserve its previous behavior after this change.
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Test the effect on the apex by following instructions in
http://b/172951145
Bug: 174226317
Change-Id: Ib8f0d9307751cc2ed34e3d9a5538d3c144666f6d
A previous change duplicated the test cases from TestGetDistForGoals()
to test the getDistContributions() method. This change removes the
duplicate tests and leaves a single test to verify that
GetDistForGoals() uses getDistContributions() and
generateDistContributionsForMake() correctly.
Test: m nothing
Bug: 174226317
Change-Id: I545501016b932f9af0d5fda2f452a3a09932d3fb
Previously, the GetDistForGoals(Module) func combined the processing
of the dist properties with generating the make specific rules for
generating that dist. That has a couple of problems:
1. It combines two pieces of functionality into one method which is
bad practice.
2. It makes it hard to test because the make specific output ends up
containing absolute paths to temporary directories created by the
test.
3. It makes switching to a non-make output difficult and fragile as
changing the output will also require changing the tests.
This change adds an intermediate data structure to contain the result
of the dist processing. That processing is done by the new method
getDistContributions(Module) which returns the new intermediate
structure. It also adds generateDistContributionsForMake(..) to
generate the make output. The GetDistForGoals(Module) func uses them to
implement the previous behavior.
It adds identical tests to those in TestGetDistForGoals() but leaves
those tests alone to show that this refactoring does not change the
behavior. Follow up changes will clean up TestGetDistForGoals(). It
also adds a test for generateDistContributionsForMake(..).
Bug: 174226317
Test: m nothing
m dist sdk - before and after this change, compare result to
make sure that there are no significant differences.
Change-Id: I458b7c8e4485bf66d3498f50df85a8d65fc2ee00
Previously, TestGetDistForGoals tested multiple test cases within a
single test so when it failed it was difficult to determine which test
case was the cause. This change runs each test case as its own
nested test.
It also corrects the order of expectedLine and line format parameters
to match the order in the message.
Test: m nothing
Bug: 174226317
Change-Id: I1408ec4125afc5c0b392cd7643dd3f630fe468e5
No current use cases for soong.config and user-editable local
configuration options for Soong, so let's remove it to reduce the API
surface.
The MegaDevice configuration is used for building every module, for
every cpu variant, for every architecture, but it apparently isn't
used for a while now.
Test: m nothing
Test: TH
Fixes: 174188200
Change-Id: I2550e70ff6f9c8b57e9a7cc517d6a119a032a27a
This is to facilitate consolidation of compatibility suite logic.
Test: m nothing and compare soong Android mk files -- no diffs
Change-Id: Ibc60d14fdde93835124e18a5c484bbda496bdb9e
Relands Ic22603a5c0718b5a21686672a7471f952b4d1017 with a minor
change to track libc++ dependencies for python hosts and after
a fix to an internal genrule that depended on transitively
installed java libraries (ag/13068670).
Soong currently assumes that installed files should depend on
installed files of all transitive dependencies, which results
in extra installed file dependencies through genrules, static
libs, etc.
Annotate dependency tags for dependencies for which the
installed files are necessary such as shared libraries
and JNI libraries.
This avoids extra installed files, and is also a first step
towards genrules using their own copy of tools instead of
the installed copy.
Bug: 124313442
Test: m checkbuild
Test: java.TestBinary
Test: cc.TestInstallSharedLibs
Test: deptag_test.go
Change-Id: I725871249d561428e6f67bba6a7c65b580012b72
This CL improves the clarity of the non-hermetic nature of using
HostSystemTools, and make the build fail if a caller tries to use a host
system tool that isn't allowlisted in config.go.
The only caller seems to be for xcrun, which is a special case that is
pretty hard to remove.
Test: TH presubmit
Change-Id: Icd3e7330406a08c00ac9682e37e2d42669f2e6b7
* changes:
Add java_data parameter to python modules
Use local variations for python version splits
Support SourceFileProducer in android.OutputFilesForModule
Add support to android.OutputFilesForModule to get paths from a
SourceFileProducer as well as an OutputFileProducer.
Bug: 173977903
Test: m checkbuild
Change-Id: I4b2ca2837342ddbb4210bee8f549a636d8b8b049
This relands I3b918a6643cea77199fd39577ef71e34cdeacdb1 with a fix
to create the directory for the output depfile if doesn't exist.
In preparation for more complicated sandboxing that copies tools
and/or inputs into the sandbox directory, make sbox use a textproto
input that describes the commands to be run and the files to copy
in or out of the sandbox.
Bug: 124313442
Test: m checkbuild
Test: rule_builder_test.go
Test: genrule_test.go
Change-Id: I8af00c8c0b25a92f55a5032fcb525715ae8297c2
Mostly documentation changes, but includes a few refactorings like
changing the variable names, reording functions, reordering statements
in logical order, etc.
Bug: 173472337
Test: m
Change-Id: I000c76e818722ed06bac03d9de87588b23552b08
Make sure every exported function or type has a godoc comment.
Also makes minor changes like unexporting functions that are not used
outside the package and fixing minor style warnings.
Bug: 173449605
Test: m checkbuild
Change-Id: I533a595d02035aae8b2b603590be639826d2d4c8
PackagingBase is the base struct that implements the basic packaging
functionalities. Here, packaging means grouping dependencies into an
output file where the built artifacts from the dependencies are placed
in a directory-like structure in the output file. The exact format of
the output file is irrelevant; it could be a filesystem image, tar.gz,
zip, or whatever.
PackagingBase is responsible for traversing the dependencies and copying
their outputs under the package root directory, which is expected to be
provided by the module type that includes PackagingBase. Then the
concrete module type is expected to do final step of converting the
package root directory into the output file of specific format.
Bug: 159685774
Bug: 172414391
Test: m dist out/dist/cvd-host_package.tar.gz
Change-Id: I5446eee4834ce3b6f0f5843d93bb330a26d42fe3
In preparation for more complicated sandboxing that copies tools
and/or inputs into the sandbox directory, make sbox use a textproto
input that describes the commands to be run and the files to copy
in or out of the sandbox.
Bug: 124313442
Test: m checkbuild
Test: rule_builder_test.go
Test: genrule_test.go
Change-Id: I3b918a6643cea77199fd39577ef71e34cdeacdb1
* changes:
Store ndkKnownLibs in the config
Register the kythe singleton on the Context instead of globally
Store ninja file deps from PackageVarContext in the config
Store SingletonMakeVarsProviders in the config
Currently, installation of a module is defined as an action of copying
the built artifact of the module to an install path like out/soong/host
(for host modules) and out/target/product/<device>/<partition> (for
device modules). After the modules are installed, the installed files
are further processed to create packages like system.img, vendor.img,
cvd-host-package.tar.gz, etc.
This notion of installation seems to have originated from the old time
when system.img is the primary product of the entire build process
(modulo a few more like root.img). Packaging the installed files as the
filesystem image was considered as a post-build step then.
However, this model doesn't seem to fit well to the current and future
environment where we have a lot more filesystem images (system, vendor,
system_ext, product, ...). The filesystem images themselves are even
grouped together to form a higher-level filesystem image like super.img.
Furthermore, things like cvd-host-package.tar.gz requires us to be able
to group some of the host tools in a format that isn't filesystem image.
Lastly, we are expected to have more filesystem images that are subsets
of system.img (and their friends) for the Android-like mini OS that will
be running on on-device virtual machines. These all imply that the
packaging (which we call installation today) is not a global post-build
step, but a part of the build rules for creating the package-like
modules.
A model better fits to the new sitatuation might be this; a module
specifies its built artifact and the path where it should be placed. The
latter path is not rooted at out/. It's a relative path to the root
directory which will be determined by another module that implements the
packaging. For example, cc_library will have ./lib (or ./lib64), not
out/target/product/<device>/<partition>/lib as the path. Then packages
like system.img, cvd-host-package.tar.gz, etc. are explicitly modeled as
modules and they have deps to other modules. Then the modules are placed
at the relative path under the package root, and the entire root
directory finally is packaged as the output file (be it img, tar.gz, or
whatever).
PackagingSpec is the first step to implement the new model. It abstracts
a request to place a built artifact at a certain path in a package. It
has extra information about whether the path should be a symlink or not,
and whether the path is for an executable. It currently is created when
InstallFiles (and its friends) are called, and can be retrieved via
the new method PackagingSpecs().
In this CL, no one is using PackagingSpec. The installation is still
done by the existing rules created in InstallFiles, etc. and the
structs are not used for the filesystem images like system.img.
Bug: 159685774
Bug: 172414391
Test: m
Change-Id: Ie1dec72d1ac14382fc3b74e5c850472e9320d6a3
This removes the need to source bazelenv.sh for USE_BAZEL_ANALYSIS, and
unifies mixed builds to use the checked in tools/bazel and bazelrc.
It also unifies all bazel-related output to be in out/bazel.
Without aosp/1502095, this change still requires toplevel_output_directories to be an empty
list, otherwise there'll be this error:
ERROR: Directories specified with toplevel_output_directories should be
ignored and can not be used as sources.
Test: With aosp/1441774: rm -rf out/ && lunch aosp_cf_x86_auto && USE_BAZEL_ANALYSIS=1 m libc && prebuilts/build-tools/linux-x86/bin/ninja -f out/combined-aosp_cf_x86_auto.ninja -t commands libc | grep bazel-out | wc -l # 2 results
Change-Id: I69b217ec88da531415792bb6e04b6a194ca4718d
The documentation java_genrule_host states that it creates a single
variant, which would make it work with the single variant fallback
in AddDependency used by the data property, but it actually has a host
and a host-cross windows variant. Modify osMutator to take the
OS-specific enabled properties into account to skip creating variants
that will immediately be disabled so there is a single variant.
Test: m checkbuild
Change-Id: Ic2daab29f4fa3a3797d7a08348fbfcf1036ec5dc
The HostOrDeviceSupported enums have become unwieldy, replace them
with bitfields to simplify checking if a specific trait is set.
Test: Soong arch tests
Test: m checkbuild
Change-Id: I884ddd092d4c6f740def611b6a055007dc24bd6e
This allows mixed builds to continue functioning even given the toplevel
WORKSPACE file containing toplevel_output_directories with out/.
Test: Manually verified on aosp_flame building libc.
Change-Id: I80fc4853421317e2d2c7f03d92d58286df1342ce
In preparation for more complicated sandboxing support in sbox, use
a single implementation of the sbox sandboxing by moving genrule to
use RuleBuilder's sbox support instead of creating an sbox rule
directly.
Also move genrule's input list hash support into RuleBuilder.
Test: genrule_test.go
Test: rule_builder_test.go
Change-Id: I292184d02743c7e6887ebbcd232ba565db2ab0cc
Store ninja file deps from ExistentPathForSource on a
PackageVarContext in the config instead of the PackageContext, as
the PackageContext may be shared between multiple tests running
in parallel.
Test: all soong tests
Change-Id: Ib1809a4dd4a82696e0fe48a87eac21a44684ecb5
Store SingletonMakeVarsProviders in the config instead of a global
variable to avoid races between tests running in parallel.
Test: all soong tests
Change-Id: I2ab64f368b5ac673fd985399d4421ed018abc562
The android.WriteFile rule takes careful escaping to produce the
right contents. Wrap it in an android.WriteFileRule that handles
the escaping.
Test: compare all android.WriteFile outputs
Change-Id: If71a5843af47a37ca61714e1a1ebb32d08536c31
Soong currently assumes that installed files should depend on
installed files of all transitive dependencies, which results
in extra installed file dependencies through genrules, static
libs, etc.
Annotate dependency tags for dependencies for which the
installed files are necessary such as shared libraries
and JNI libraries.
This avoids extra installed files, and is also a first step
towards genrules using their own copy of tools instead of
the installed copy.
Bug: 124313442
Test: m checkbuild
Test: java.TestBinary
Test: cc.TestInstallSharedLibs
Test: deptag_test.go
Change-Id: Ic22603a5c0718b5a21686672a7471f952b4d1017
Prepare for using Config when adding singletons by passing
Config to NewTestContext and NewContext instead of to ctx.Register.
This will enable a followup change to store SingletonMakeVarsProviders
registered on the Context in the Config, which is necessary to run
multiple tests in parallel without data races.
Test: all soong tests
Change-Id: Id229629a4e42ff4487d317241673837726c075fc
If SOONG_DELVE_PATH=<path> is set, Soong will use that as the path to
dlv. Otherwise, it will use the one on $PATH as usual.
Test: Manual.
Change-Id: Id4334f05d077a911750f601865bd3096d852d69c
Bazel overlay is an experimental feature. This renames the feature to 'queryview' to better describe its purpose, and also move away from the already overloaded 'overlay' term in Android.
Test: m queryview && bazel query --package_path=out/soong/queryview //...
Change-Id: I8b5068c7db46cb61a03a8e87af9c7c9077ebeff9
This was caught while running the soong_build docs action under Bazel as
ninja executor. Since the config file is not an explicit input to the
action, it's not present in Bazel's execution root during action
execution time, leading to a missing file error. To fix it, add the file
as an input to the action, if it's configured in product variables.
New soong_build statement:
build out/soong/docs/soong_build.html: s.writedocs.soongDocs $
out/.module_paths/Android.bp.list out/soong/soong.variables $
out/soong/dexpreopt.config | out/soong/.bootstrap/bin/soong_build
outDir = out/soong/docs
Test: m
Test: USE_BAZEL=1 m
Bug: 161958189
Fixes: 161958189
Change-Id: I2bf264e848bb29ac91f4196fbe9c4ecf3cea8a2c
Adds a singleton that traverses the module variants finding the ones
that are in the list (updatable and non-updatable) of boot jars and
add a ninja rule to ensure that they only contain packages from an
allowed list.
Replaces a hack that ignored any prebuilt boot jars supplied as dex
file with an equivalent one to ensure that they are still ignored.
A follow up change that switches to checking dex jars will allow the
hack to be removed.
The boot jars check can be strict or lax. If strict then all the boot
jars listed in the configuration must be found, otherwise it will only
check the ones it finds. It is strict by default unless
TARGET_BUILD_UNBUNDLED=true or ALLOW_MISSING_DEPENDENCIES=true.
Moves the script and data file from build/make.
Test: m check-boot-jars - for failing and passing cases
SKIP_BOOT_JARS_CHECK=true - no check-boot-jars target created
ALLOW_MISSING_DEPENDENCIES=true - not strict
TARGET_BUILD_UNBUNDLED=true - not strict
verified manually that apart from path differences the same
files (same check sum) were checked in both old make checks and
the new Soong ones
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m check-boot-jars
Bug: 171479578
Change-Id: I9d81d6650ba64fc0d48d2dab4ba5a3ba8dd03dec
This adds an extra step to mixed builds: creating a master BUILD/bzl
file pair to facilitate running a single cquery command to analyze
all soong->bazel edges in a single request.
Test: Mixed build tested with aosp/1441774, verified ninja outputs
depend on `bazel-out/` intermediates
Test: Manually verified contents of master BUILD and bzl files
Change-Id: I04803bcc91ac4182578f505b3f42893061ddd167
As a result, one can enable bazel-as-ninja-executor separately from
mixed builds.
Test: Manually verified building image with and without bazelenv.sh.
Change-Id: Ia97806fb41e1de850a80b9483ed8a5ff50d9dab2
By making the Append and RemoveList methods return a new list instead
of modifying the existing list it makes the ConfiguredJarList usages
easier to reason about and safer to use, especially considering that
they are primarily used in global configuration.
Added some tests for Append/RemoveList to ensure that they work and
do not modify the original or result in newly created lists sharing
storage with the original which would lead to corruption.
Bug: 171756871
Bug: 171479578
Test: m nothing
EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m nothing
Change-Id: I541c4686ecdd45c6a0c8b1c93fedf0fcd5952e2b
After previous refactorings the CreateConfiguredJarList function is now
only used in tests and are supplied with a PathContext that will cause
ReportPathErrorf() to panic. So, this change removes the ctx parameter,
calls panic directly on any error and renames the method to make it
clear that it is for testing only.
Bug: 171479578
Test: m nothing
Change-Id: Icfb4bdfe720afa855b64ecf0e74a0b030882d029
This change:
* Switches BootJars/UpdatableBootJars fields of config.productVariables
from []string to ConfiguredJarList.
* Updates BootJars() method to simply concatenate the jars list from
the BootJars/UpdatableBootJars fields.
* Adds an UnmarshalJSON(..) method to ConfiguredJarList to support
unmarshalling from a single string array to avoid having to change the
format of the JSON file from which the configuration is loaded.
* Adds some additional calls to ConfiguredJarList(..) in tests to
convert from []string to ConfiguredJarList. They pass nil as the
ctx argument as there is no suitable PathContext which will cause any
errors to be thrown using panic. That is reasonable for hard coded
values in tests. A follow up change will clean up the calls to
ConfiguredJarList(..).
Bug: 171479578
Test: m nothing
Change-Id: I59b94dafb479ccd8f0471ed802be175af57be271
This change:
* Changes splitConfiguredJarPair to return an error rather than
reporting it through the context.
* Extracts the splitting of a list of pairs into a pair of lists into a
new splitListOfPairsIntoPairOfLists() method for reuse in a follow up
change.
Bug: 171479578
Test: m nothing
Change-Id: I824ed1bc673b47757424563fc37e1190adff2ed1
... and ramdisk_available modules. If a module is both
vendor_ramdisk_available and ramdisk_available, on a device
that mark recovery_as_boot and move_recovery_resources_to_vendor_boot
simultaneously (and incorrectly),
both will be installed to recovery/root/first_stage_ramdisk. Fix the
path conflict of the two variants by moving the vendor_ramdisk variant
to vendor-ramdisk/first_stage_ramdisk instead.
Also update comments for Vendor_ramdisk_available.
Test: m nothing -j
Bug: 156098440
Change-Id: I2b776b6fd8f5a2c361c0f6a89231e3cebc2646f0
By making the Append and RemoveList methods return a new list instead
of modifying the existing list it makes the ConfiguredJarList usages
easier to reason about and safer to use, especially considering that
they are primarily used in global configuration.
Bug: 171479578
Test: m nothing
Change-Id: I102c4fb42f0c54e4ed299d2921fbf5efeb6e99b9
This is only used from within the ConfiguredJarList implementation and
provides no real benefit over directly accessing the apexes slices.
Similarly, uses of Jar(int) from within the implementation are also
replaced with direct slice access.
Bug: 171479578
Test: m nothing
Change-Id: I7e799b1049f4a1da4140e55831c4559751278de6
Install to recovery/root/first_stage_ramdisk if
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT,
otherwise vendor-ramdisk. In addition, append /system
if not InstallInRoot().
On devices with dedicated recovery partition,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is not set,
and this installs to the correct place (under $OUT/vendor-ramdisk).
On devices without a dedicated recovery partition:
- To install a module available before switching root
to /first_stage_ramdisk, e.g. a binary under /system/bin,
use recovery{_available} and install the recovery variant
of the module.
- To install a module available after switching root
to /first_stage_ramdisk, e.g. a binary under
/first_stage_ramdisk/system/bin,
use vendor_ramdisk{_available} and install the vendor_ramdisk
variant of the module.
Test: pass
Bug: 156098440
Change-Id: I1af3f8889891a3e58263cda36f0680ce2b480499
Add vendor_ramdisk_available and vendor_ramdisk attribute to
various rules. When a vendor_ramdisk variant of a module is
generated, it is installed to $OUT/vendor-ramdisk.
It is similar to a ramdisk image.
Test: m nothing -j
Change-Id: Ib2d16459f3094dbe21c3bdb7c016cb4b2bf62765
This change introduces the concept of partition dir for InstallPaths.
It's the path to the partition where the InstallPath is rooted at. For
example, it's out/soong/target/product/<device>/<partitoon> for paths
created for device modules. For host modules, it is defined as
out/soong/host/<host_os>-<host_arch>.
The partition dir is obtained using the new PartitionDir() function.
Another change is that a freshly created InstallPath (usually via
PathForModuleInstall) is the result of joining PartitionDir() and the
remaining path elements. For example, PathForModuleInstall(ctx, "foo",
"bar").Rel() now returns "foo/bar". Previously, that call returned the
relative path from config.buildDir() ("out/soong"). This change is in
line with the behavior of other path-creating functions like
PathForModuleSrc where Rel() returns the path relative to the
contextually determined path like the module source directory.
Notice that the Join() call to InstallPath doesn't change
PartitionDir(), while does change the result of Rel().
p := PathForModuleInstall(ctx, "foo", "bar")
p.PartitionDir() is out/soong/host/linux-x86
p.Rel() is foo/bar
q := p.Join(ctx, "baz")
q.PartitionDir() is still out/soong/host/linux-x86
q.Rel() now returns baz
Bug: N/A
Test: m nothing
Change-Id: I916bb1c782a4bfe0fbd4854e349cd2a2a42f56b6
Prepare for making the relationship between an llndk_library stubs
module and the cc_library implementation module explicit by
adding an llndk_stubs property. Each cc_library will be updated
to point to its llndk_library, and the llndk_library name will
be changed to make the .llndk suffix explicit. Then the implicit
connection and suffix can be removed.
Bug: 170784825
Test: m checkbuild
Change-Id: I6b0482a3f286ec29b2e928551aa4317749f2b499
This CL adds symlink_outputs to various locations in Soong that creates
actions that creates symlink outputs, and explicitly mark them as such.
Test: m
Bug: 160568334
Change-Id: I322751bada52a9f49011c74731d84761586e03e7
Clarify that only __pkg__ and __subpackages__ are valid package
visibility specifications.
Test: go test soong tests
Test: m nothing
Bug: 168926331
Change-Id: I810e9ef92d081d85cd762e7f8c0b0716f0222883
Expands the error to suggest a potential fix, giving the package path
for the module that needs visiblity.
Test: go test soong tests
Bug: 168926331
Change-Id: Ie95dec03f5e2c3190bfaed1f0e5789eeb0ab1878
This retriggers soong_build whenever a new bzl, WORKSPACE, or
BUILD.bazel file is changed or added.
Test: Manually verified on bionic/libc genrules with manual changes to
related BUILD/bzl/WORKSPACE files -- these all retrigger builds.
Test: Updated finder_test.go
Change-Id: I634384f88781a6b6db32f5d6bf9c07e179e14c39
In apex_set and cc_prebuilt_library_*, provide a way to specify an
alternative source to use when build with sanitizers.
Test: prebuilt_test, apex_test
Change-Id: I1ab8091bf696d94da3547cf5248853df489bdee6
Export information about static libraries, shared libraries and
exported flags through Providers instead of accessing the module
directly. Much more is left to be converted, but this significantly
simplifies the dependencies on libraries with stubs by making it easy
for a module to masquerade as another by simply exporting the
providers from the other module. Instead of depending on all the
versions of a library and then picking which one to use later, it
can depend only on the implementation variant and then select the
right SharedLibraryInfo from the variant.
Test: m checkbuild
Test: only expected changes to build.ninja
Change-Id: I1fd9eb4d251cf96ed8398d586efc3e0817663c76
Let the flakes, and the crashes, and the deadlocks, and the leaks, and
the undefined behavior which steals away so many nights find their
numbers decimated in the homogeneous conditions we now rest our data.
To give some intuition why this is not so underperformant, zeroing
memory is one way of priming caches.
This change is actually a no-op, because build/make/core/soong_config.mk
always overrides this setting, but it reflects the spirit and future
direction of this change.
Bug: 131355925
Test: basic simple perf comparisons
Change-Id: I8254c36373de52091839561973c9741e8f85aa09
With this change, users don't need to figure out which libraries
actually hold the resources to be overlaid when targetting apps with a
core lib dependency (e.g. Settings, SystemUI).
Fixes: 169898727
Test: app_test.go
Change-Id: I3c3b9dc0a377b1828db1199858a73d080a173205
Targets[Android][0] is not always the first, preferred target. Add a new
field to config to provide the correct target and begin to use it.
Test: m nothing
Test: build/soong/scripts/build-ndk-prebuilts.sh
Fixes: 156980228
Change-Id: Ib56f52424ebf47f3eee6ac62b9fd9eca2919d63a
stderr is a bytes.Buffer, but the String() method has a pointer
receiver, so stderr does not satisify the Stringer interface
and can't be used for a %s argument. Make stderr a *bytes.Buffer
instead.
Test: go vet ./android
Change-Id: I994402cb954946279375c9d447ad3854380381cc
ctx.PrimaryModule() is wrong in the case of a java_binary that
supports both host and device, use an explicit dependency instead.
Once the dependency exists there is no need to manually request
the jar be installed, it will automatically be installed by the
host installation rules for dependencies.
Test: TestBinary
Change-Id: Iddeea2d08bc574c79d42139020558cd70d718ca1
This reverts commit 323dc60712.
Reason for revert: Possible cause of test instability
Bug: 170513220
Test: soong tests
Change-Id: Iee168e9fbb4210569e6cffcc23e60d111403abb8
With this change, bazel_module is a specifiable property on
genrule module definitions. With bazel-enabled mode, soong_build will
defer to Bazel for information on these modules.
source build/soong/bazelenv.sh to enter bazel-enabled mode.
Test: Manually verified on bionic/libc genrules using aosp_cf_x86_phone-userdebug
Change-Id: I3619848186d50be7273a5eba31c79989b981d408
Putting t.Parallel() in each test makes them run in parallel.
Additional t.Parallel() could be added to each subtest, although
that requires making a local copy of the loop variable for
table driven tests.
Test: m checkbuild
Change-Id: I5d9869ead441093f4d7c5757f2447385333a95a4
A global variant was used to store the global mapping between
modules and APEXes. Replace it with storing pointers to APEX
contents inside each module so that they can query the contents
of any APEXes they belong to.
Bug: 146393795
Test: all Soong tests
Test: single line change to build.ninja host install dependency ordering
Test: no Android-${TARGET_PRODUCT}.mk, make_vars-${TARGET_PRODUCT}.mk or late-${TARGET_PRODUCT}.mk
Change-Id: Id2d7b73ea27f8c3b41d30820bdd86b65c539bfa4
* changes:
Don't create version variations of sdk modules
Create fewer empty version variants
Don't make SplitPerApiLevel imply UseSdk
Remove vendor crt special case
Fix apex_test.go and add it to Android.bp
apex_test.go wasn't listed in the Android.bp file, which allowed
it to bitrot. Make the API level methods take a PathContext
so that they can be called from a test using configErrorWrapper.
Also fix an int that was converted to a string.
Test: apex_test.go
Change-Id: I1ff87134c837bd5d344d22550baabde10d1b0b2e
Some mainline modules provide an `sdk` and one or more set of
module_exports. When the snapshots are unpacked into separate prebuilts
directories (one per snapshot) then any dependencies from a member of
one snapshot to a member of another may require the latter to have
additional visibility rules.
Previously, these rules had to be added to each source module. This
change allows additional visibility rules to be specified on the
sdk/module_exports that are added to all the prebuilts in its snapshot.
Bug: 155921753
Bug: 168301990
Test: m nothing
Change-Id: Ia3eacb5749981f04770ae9872a8013e43c5c6ef1
This change ensures that each prebuilt in a snapshot explicitly
specifies its visibility even when that visibility is the current
default. This is done for two reasons:
1. It simplifies a follow up change that adds visibility rules to an
existing set of rules.
2. It ensures that the snapshots are independent of the current Soong
default visibility.
The latter is important because we intend to switch from modules being
visible to everyone by default (i.e. //visibility:public) to only being
visible to modules in the same package (i.e. //visibility:private). By
making the snapshots of modules that do not specify any visibility
explicitly specify that they are "//visibility:public" it ensures that
the snapshots will not need to be changed when the default changes.
Bug: 168301990
Test: m nothing
Change-Id: Ia034f4a1e5124c17f46d73b0e9a6c5f2a251038e
Instead of tracking per module and per module variant, track allowed
list of dependecies for all modules combined. This avoids issues with
different products and different downstream branches having different
build graphs.
To compare allowed_deps.txt vs head, run:
:; m -j out/soong/apex/depsinfo/new-allowed-deps.txt.check
To update source allowed_deps.txt, run:
:; build/soong/scripts/update-apex-allowed-deps.sh
Bug: 149622332
Test: m
Change-Id: Ic518fbd9ebfe1b46aaf9a58df731780a7e5a676b
Merged-In: Ic518fbd9ebfe1b46aaf9a58df731780a7e5a676b
(cherry picked from commit 453555083b)
(cherry picked from commit e5207cd9a6)
It will be used by the cvd_host_package module type to gather installed
files and package them in a distributable format.
Bug: 168086242
Test: m
Change-Id: I3af6dcda0bce1f298b1500fbac311c9593ddf375
I2954bb21c1cfdeb305f25cfb6c8711c930f6ed50 switched normalizeVersions
to work on ApiLevels, which inadvertantly caused it to return "current"
instead of "10000" for libraries that specify "current" in their stubs
property. ChooseSdkVersion couldn't handle "current" because it was
manually converting the version to an int. Switch ChooseSdkVersion
to use ApiLevels instead so that it can handle "current".
Test: m checkbuild
Change-Id: Id412359e092483ba419118dd03bc206fae702a96
Mulitple init_rc files may be necessary to support multilib binaries
with different installed names.
Test: m checkbuild
Change-Id: I17d3a3b2346a25b230e5a325deb0d78f0ee045f0
R is out. The platform codename on the main branch is now S and the API
level of the platform is 30, which is R because S hasn't been finalized.
Bug: N/A
Test: rm -rf out; ./build/soong/soong_ui.bash --make-mode --skip-make
Change-Id: I486b9639bccfe17a42681e1f84097373f8f401e7
Both will create a nested property set, that may be merged with an
existing one.
Test: m nothing
Bug: 151303681
Change-Id: I30696ba3eb8960ca6fa54c9ee2cf6229ab9f5da9
linux_bionic_arm64 is the new host target using Bionic as libc. This
change adds a new Soong config Host_bionic_arm64 that enables the
target.
This change also amends firstTarget() function to handle the case when
the available targets for an OS have different arch families. In that
case, first target is selected for each of the arch family. This is
needed in the (rare) care when both linux_bionic_x86_64 and
linux_bionic_arm64 targets are enabled.
Bug: 159685774
Test: add "Host_bionic_arm64": true to out/soong/soong.config and run
./build/soong/soong_ui.bash --make-mode --skip-make
out/soong/host/linux_bionic-arm64/bin/aarch64-linux-bionic/crosvm
Change-Id: I0885e49379f6ee216c6e82adbb1230655171a7a5
A host target is considered as being cross-compiled when the target
can't run natively on the build machine. For example, linux_glibc/x86_64
is a non-cross target on a standard x86/Linux machine, but is a cross
host on Mac. Previously, whether cross or not was a static attribute of
an OsType. For example, Windows was always considered as cross host,
while linux_bionic was not. This becomes a problem when we support more
host targets like linux_bionic/arm64 which should be cross-host on
standard x86/Linux machines.
This change removes HostCross from the OsClass type and instead adds a
property HostCross to the Target type. When a target is being added, it
is initialized to true when the target can't run natively on the current
build machine.
Bug: 168086242
Test: m
Change-Id: Ic37c8db918873ddf324c86b12b5412952b0f2be2
The test case I removed is invalid. The codename has had its int
assigned, but the config claims it is not final.
If this ever does need to be supported it's just a matter of making
sure the Q -> 29 mapping (or whatever) in the finalized codenames map
in android/api_levels.go.
Test: treehugger
Bug: http://b/154667674
Change-Id: I4f42ec2fd4a37750519ee3937938a1c65b6bb1e8
Keeping the int constant around for now as FutureApiLevelInt because
it's still useful in places that haven't adopted ApiLevel yet for
testing if their non-ApiLevel API level is current or not.
Test: treehugger
Bug: http://b/154667674
Change-Id: I47a7012703f41fdeb56f91edf9c83afa93042deb
Can happen if OUT_DIR is set on an absolute path.
Test: env RBE_remote_disabled=true OUT_DIR=/home_2/tmp/out m
Bug: 169048540
Fixes: 169048540
Change-Id: Ia6b91b13142d84e54d0dee8b4e04a91ad2cecc36
Handling of API levels within Soong is currently fairly difficult
since it isn't always clear based on context what kind of API level a
given string represents, how much canonicalizing and error checking
the code receiving the string are expected to do, or how those errors
should be treated.
The API level struct does not export its raw data, so as to keep its
"constructor" private to the android package, and to prevent misuse of
the `number` field, which is only an implementation detail for preview
API levels. API levels can be parsed with either
`android.ApiLevelFromUser`, which returns any errors to the caller, or
`android.ApiLevelOrPanic`, which is used in the case where the input
is trusted and any errors in parsing should panic. Even within the
`android` package, these APIs should be preferred over direct
construction.
For cases where there are context specific parsing requirements, such
as handling the "minimum" alias in the cc module,
`nativeApiLevelFromUser` and `nativeApiLevelOrPanic` should be used
instead.
Test: treehugger
Bug: http://b/154667674
Change-Id: Id52921fda32cb437fb1775ac2183299dedc0cf20
Move PrimaryModule, FinalModule, and VisitAllModuleVariants to
BaseModuleContext so they can be used by mutators.
Test: m checkbuild
Change-Id: I4280333f19283edc8f65fc4af6f49b654af31782
Copy documentation from Blueprint for interface methods that are
wrapped into Soong interfaces.
Test: m checkbuild
Change-Id: Ib58c9201b8e7dfbf900a252e709f0a3cfed73286
Propagate new return values of the BottomUpMutatorContext.Add*
methods from https://github.com/google/blueprint/pull/316 to
Soong.
Test: m checkbuild
Change-Id: I5378db46adf2f31cc4222b4619cc39db53791610
And remove dual meaning from arm_on_x86 target. It was set for x86
targets with arm support and for arm targets with x86 support - and that
2nd one was abused for native_bridge version of RenderScript.
It's much safer and cleaner to rely on __ANDROID_NATIVE_BRIDGE__ there
while leaving arm_on_x86 to mean "x86 binary built in the image with arm
support".
It's only used by bcc compiler which is in canadian-cross situation here:
it's pure x86-64 binary, but it needs to know about ALL supported
architectures on device because it needs to include appropriate codegen
module.
Bug: http://b/153609531
Test: cts-tradefed run cts --abi armeabi-v7a -m CtsRsCppTestCases
Test: cts-tradefed run cts --abi arm64-v8a -m CtsRsCppTestCases
Change-Id: I869212e0b82eeaa30361a4e183d5c862ab40ef12
Previously, disabled modules were able to emit make vars and this could
cause duplicated make var definitions when a prebuilt_build_tools is
enabled for both linux_glibc and linux_bionic.
Bug: 159685774
Test: m
Change-Id: I8570ae5aabb8199e7c3901921886bcfa849037fe
AddFarVariationDependencies was broken, which allowed modules to add
dependencies on bootstrap Go modules using os and arch variations
even though boostrap Go modules did not have any variations. Mutate
bootstrap Go modules in the os and arch mutators so that they have the
expected os and arch variations.
This relands Ida7bc75a51ab1d2d38a6be11f574399097380cc9 with fixes
to also mutate *bootstrap.goPackage modules so that they can find a
matching *bootstrap.goBinary module when creating their pluginFor
dependency, and to create a variation for linux_bionic when it is
enabled so that linux_bionic builds can package Go binaries.
Also requries https://github.com/google/blueprint/pull/320 to
support multiple variants of bootstrap Go modules.
Test: all soong tests
Change-Id: Ibc627aa262c298a076d171a4c21b0b9c2a7b0ada
LinuxBionic now supports arm64 architecture in addition to the existing
x86_64 arch. This is to make it possible to build host tools like adb,
fastboot, crosvm, etc. for Linux/ARM on regular Linux/x86 machines.
The arm64 target can be selected in various ways in Android.bp files:
- target.host (because this is still considered as a host target)
- target.linux (provided that the module is also enabled for host)
- target.linux_bionic (use the OS name directly)
- target.linux_bionic_arm64 (OS name + arch combo)
- target.linux_arm64 (provided that the module is also for host)
- target.not_windows
- arch.arm64
The toolchain for the new target is almost the same as the toolchain
config for Android/ARM64. One notable difference is that the clang
triple is aarch64-linux instead of aarch64-linux-android, so that
__ANDROID__ is not defined for the new OS type.
Bug: 134795810
Test: HOST_CROSS_OS=linux_bionic HOST_CROSS_ARCH=arm64 m nothing
Change-Id: If4300583edfb6d75bd4d984b38f73b6a406b4447
This change fixes some places where host arch is assumed to be x86 to
form a path element like linux-x86. In preparation for non-x86 host
targets, the host arch part is derived from the context.
In addition, InstallForceOS() is refactored so that it can override not
only OsType, but also ArchType. Without this, the paths for the
robolectic modules will be changed from linux-x86 to linux-common, which
breaks several other places where the old paths are expected.
Bug: 134795810
Test: m
Change-Id: Ib38c715948ae546e55021ece82bac1d82e9e5da0
The commonProperties and defaultsVisibilityProperties fields are only
used as containers for default values for properties and only within
the InitDefaultsModule() and so can be removed and replaced with an
empty structure instead.
Test: m checkbuild and TH
Change-Id: Ic5038d6b84b33afdf4859ced08e59871b9cde4a2
Common properties are automatically inherited from a parent module
(i.e. one that calls CreateModule()) to the child module that it
creates. This makes no sense for dist/dists properties so this change
extracts them into their own structure separate to the
commonProperties.
Test: m checkbuild and TreeHugger
Bug: 160448975
Change-Id: Icceb20455e13394dd3b3bce464fb9bb34882d6c3
Similarly to Output, we return the list of Rules that have been
generated for TestingModule. This helps debugging failing tests.
Test: m nothing
Change-Id: I3542f4e4632f94fb84208c2e48e629271a373fd4
If BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES has a numeric value,
it replaces "current" or "system_current" with the version which
the flag indicates.
Bug: 163009188
Test: BOARD_CURRENT_API_LEVEL_FOR_VENDOR_MODULES=29 m, and then check if every vendor
java module's sdk_version is 29 if its sdk_version was current.
Change-Id: I17b49b8e02caf2d1bc57b91648d4420f3ad9fcb9
In order to rely on `-march`/`-mcpu` compiler flags for feature
detection, we introduce a new arch variant based on armv8.2 with the
addition of dot product features.
Test: test-art-target on Pixel 4.
Change-Id: I4d97db6129e2cd718a2b21008d36ec767739f925
AddFarVariationDependencies was broken, which allowed modules to add
dependencies on GoBinaryTool modules using os and arch variations
even though GoBinaryTool modules did not have any variations. Mutate
GoBinaryTool modules in the os and arch mutators so that they have the
expected os and arch variations.
Test: all soong tests
Change-Id: Ida7bc75a51ab1d2d38a6be11f574399097380cc9
Chris Parsons