Most of the fields in the bootImageConfig/Variant structs are assigned
inside a Once func so are guaranteed to be only set once. However, some
are assigned outside. This change adds comprehensive tests for those
structs and verifies that the constant fields are preserved and the
mutated fields have the correct value.
The check for the constant fields is added in a new TestBootImageConfig
test.
The check for the mutated fields is added into
TestSnapshotWithBootclasspathFragment_ImageName as that test checks an
art bootclasspath_fragment in the following configurations:
* source on its own
* prebuilt on its own
* source and prebuilt with source preferred
* source and prebuilt with prebuilt
It reveals a couple of interesting facts:
* All the *installs fields are set to the same value irrespective of
whether the source or prebuilt is preferred. The information is
constructed solely from information already within the
bootImageConfig/Variant and so can be moved within Once.
* The licenseMetadataFile is incorrect when prebuilt is preferred.
That is due to both the source and prebuilt modules setting it and
the source module always wins as the source module depends on the
prebuilt so always runs its GenerateAndroidBuildActions after it.
Those issues will be cleaned up in following changes.
Bug: 245956352
Test: m nothing
Change-Id: If917cfbcb3b1c842a8682d51cc1ee1fed1c51add
The generated Bazel workspace will only contain api specific targets.
This is feasible since these targets do not have any cross dependencies
with the targets in the bp2build workspace
The advantages of a new mode are
1. Does not pollute bp2build workspace with api targets
2. Does not block api targets with the current allowlist conversion
mechansims in bp2build
(In the future we might want to combine these two workspaces)
A Soong module type will generate a Bazel target if it implements
ApiProvider interface
Test: m apigen
Test: m nothing
Change-Id: I69c57ca6539f932e0ad554ce84a87fb7936fdba0
Previous behavior:
- Packge not listed in bp2buildKeepExistingBuildFile:
- Use bp2build generated build file
- Package listed in bp2buildKeepExistingBuildFile:
- Use handcrafted build file even if there were allowlisted bp2build
modules in the same package.
- Package listed in bp2buildKeepExistingBuildFile and a soong module has
a bp2build: { label } attribute:
- Merge the handcrafted and bp2build generated build files
New behavior:
- Packge not listed in bp2buildKeepExistingBuildFile:
- Use bp2build generated build file
- Package listed in bp2buildKeepExistingBuildFile:
- Merge with bp2build generated build file.
Bug: 234167862
Test: ./build/bazel/ci/bp2build.sh
Change-Id: Ifbaf4f8f0f5158b5b2bd6d534eb2311e2e5f399b
This was used nested in some code in the AIDL tests, but I didn't
realize that they were regexes, and well, I was trying to figure out
how identical strings were not identical.
Change-Id: Icf3114c84b804fb8f280251d0b11b06b623dfa90
This refactoring prepares for introduction of bazel prod mode, an
alternative mechanism for mixed builds allowlist handling.
* Decide bazel-mode as close to soong_build main as possible
* BazelContext itself decides whether a module is allowlisted
* Separate bp2build and mixed build allowlist
Test: m nothing, manually verified all modules are mixed build disabled
(via metrics)
Test: USE_BAZEL_ANALYSIS=1 m nothing, manually verified that mixed build
disabled/enabled modules are identical before and after change.
Change-Id: I0f55d8b85000cb4a871a099edc6d7d868d7df509
To make testing easier, refactor existing module-global variables into a
struct that can be mocked.
Test: build/bazel/bp2build.go
Change-Id: I9d177677644ea743641a745b1839a3a8b29f902a
Each conversion required defining a separate mutator, which will each
operate on _all_ modules and requires each to repeat checks whether the
mutator should operator. Instead, we introduce a single mutator and
modules can define a ConvertWithBp2build to implement bp2build
conversion for that module.
Test: bp2build.sh
Bug: 183079158
Change-Id: I99d4b51f441c2903879092c5b56313d606d4338d
output file.
PathRelativeToTop should give an unambiguous path that can be used for
matching, as opposed to Rel().
Test: `m nothing` with a test with an invalid Output() call
Change-Id: I6d501df6acb0a1700f1480bd4250320f69278c39
Can be a more convenient alternative than specifying the full subdir
concatenation of the variants. E.g. common arch and os variations don't
have to be hardcoded.
Test: `m nothing` with https://r.android.com/1801128
Change-Id: Ic2966e109d61dfee6a2b4fcbcbf8f73274babca9
These are just out/ and out/soong/ and the old names were quite
confusing.
Test: Presubmits.
Merged-In: I999ca62162062f27e449f83ffb00fa580d4065b8
Merged-In: I2fcd80a9e376a6842a06aa104a9f6f5c5e16f8c7
Change-Id: Ib481d2aac40df8da1b74174dc8ec576c1cb48be0
Refactor bp2build to retrieve modules directly by name, instead of via
DirectDeps. This functions properly as bp2build has no need for variant
information of the blueprint graph.
Test: USE_BAZEL_ANALYSIS=1 m fmtlib
Change-Id: Ief4b67bc56f24929871af772f3a742f07085bf8c
This change adds a test that includes license modules that are used by
modules which are part of an sdk but which does not yet copy the
license module into the snapshot. It includes the refactoring changes
needed to allow license modules to be used in an sdk test and provides
a baseline against which future changes can be compared.
Bug: 181569894
Test: m nothing
Change-Id: I60722f43cc9cc8375d97f46eb4c281e6c38987cd
Deprecated the method to try and prevent any other uses being added.
Bug: 183650682
Test: m nothing
Change-Id: Ia6f43851e5a00c9d96af780e3bd21e03175e1a2f
Fixes the few tests that break due to this and which cannot easily be
separated into their own changes.
Bug: 183650682
Test: m nothing
Change-Id: Ia2f31213a1f114a78e66a81d89279ecde9f4c465
Makes Path.RelativeToTop the source of truth as to what `relative to
top` means.
Uses it in PathRelativeToTop so that it will be tested by the existing
tests that use AssertPathRelativeToTop.
Also adds RelativeToTop() to WritablePaths and Paths.
Bug: 183650682
Test: m droid
Change-Id: I88dc56afd1314e51b4e41795a2448cab4ce8a899
First, the buildDir() method was renamed to getBuildDir() to avoid
clashing with the buildDir field.
Then, a buildDir was added to both `OutputPath` and `InstallPath` but
not to `PhonyPath` as it does not contain any path components. Instead
the `PhonyPath.getBuildDir()` was changed to simply return "".
Bug: 183650682
Test: m droid
Change-Id: I12e1854c829b980c5c01205753c62c00dc0a4774
This change needed to add some additional files to the registered
files for PrepareForTestWithJavaDefaultModules because otherwise they
would fail when "TestAllowNonExistentPaths = false". Those files were
being added by the TestJavaLintRequiresCustomLintFileToExist (albeit in
some cases in different locations to that required by the default
modules but as the files are needed by the modules defined in
PrepareForTestWithJavaDefaultModules they should be defined in it.
A couple of other places also provided some files so moving them into
PrepareForTestWithJavaDefaultModules caused some conflicts which needed
to be resolved.
Bug: 183184375
Test: m nothing
Change-Id: I76ce9f1673c1c1c4000635b76b8377d582224bf1
This CL adds the support for specifying lists of directories in
build/soong/android/bazel.go, which are then written into
out/soong/bp2build/MANIFEST. Using this configuration,
modules/directories can either default to bp2build_available: true or
false, while still retaining the ability to opt-in or out at the module level.
It also ensures that ConvertWithBp2Build returns true iff the module
type has a registered bp2build converter.
Test: go tests
Test: demo.sh full
Test: TreeHugger presubmits for bp2build and mixed builds.
Change-Id: I0e0f6f4b1b2ec045f2f1c338f7084defc5d23a55
This is achieved by writing soong.environment.used in Main() instead of
as a side effect of a singleton. This makes a difference because build
actions are not generated when GENERATE_BAZEL_FILES=true is set,
therefore the side effect did not happen.
Arguably, Main() is made worse by this change, but I don't want to
tackle the problem of readably determining which mode soong_build is
running in in this change.
Test: Presubmits + the additional test.
Change-Id: I66af2429aedf008762173eaaa55b828b4cf4328b
The methods returns a copy of TestingBuildParams with every usage of a
path that is relative to the temporary test build directory with a path
relative to a notional top. Similar to how PathRelativeToTop does.
Bug: 182885307
Test: m nothing
Change-Id: I6ec20fc52ed76748138f0d48b4df80f765dfcfdc
When searching for an TestingBuildParams this change will compare the
supplied path against the value returned by PathRelativeToTop() as well
as the String() and Rel() values. In the event that it cannot find the
file it also formats the available outputs, one per line with both rel
and path relative to top.
Bug: 182885307
Test: m nothing
Change-Id: Icbd37018b9a028abf37e27d1bea12a407316e031
Allows the removal of the provider parameter and makes it easier to add
new functionality to baseTestingComponent.
Bug: 182885307
Test: m nothing
Change-Id: Ie8ac600cbce982f2c5fc24a22968efe0c2a29d0c
The existing NormalizePathForTesting function does not handle make
install paths very well, as it returns a relative path with a leading
"../" which is very confusing. It also does not clearly differentiate
between the different paths.
These functions return paths that are basically what are seen in a
normal developer build, i.e.
* <source path>
* out/soong/<soong output path>
* out/<make output path>
That makes tests that use them easier to understand.
Follow up changes will clean up the existing usages of the
Normalize... functions.
Bug: 182885307
Test: m nothing
Change-Id: I17ddc996bef5bbbf4a62da8334ea6ce29e306109
This change tries to distinguish between the preparations needed for an
integration test and the preparations needed for more unit-testy tests.
Integration tests exercise most, if not all of Soong (at least the
parts that are available when running tests in a specific package) and
as a result can take a long time. Other tests, while being as realistic
as possible, should only use a subset of the preparations in order to
reduce run time.
Registering module types has very little overhead so it is simplest to
try and register those all together. However, care needs to be taken
for singletons and mutators as they can do a lot of work. Especially
with tests that include lots of default module definitions such as are
created by java.GatherRequiredDepsForTest().
Once it is possible to use test fixtures in tests it will be much
easier to customize tests individually and so avoid just adding new
test specific content to the common deps.
Bug: 181070625
Test: m nothing
Change-Id: Ia0a676297224d90df947054746e7f99563ffb323
It is no longer necessary to use preparers in a specific order now that
the test infrastructure enforces a consistent registration order.
So, this change:
* Sorts preparers alphabetically to make them easier to maintain.
* Creates a single visiblity preparer for all the visibility mutators.
* Adds PrepareForTestWithPackageModule
Bug: 181070625
Bug: 181953909
Test: m nothing
Change-Id: I9e65dd182be664d8d0d5db7ccc0b63fa315129c8
Previously, the TestContext.Register() method stored all the components
that were available, rather than just the ones that were used by the
tests. That was practically useless for debugging. This change just
stores the ones used by the test.
Bug: 181953909
Test: m nothing
Change-Id: I8589b9b4423133709ab0cfd763bd284a7f47a24a
In preparation for allowing the TestContext to enforce an ordering on
the registration of singletons and pre-singletons in the same way as it
does for mutators this defers the registration of them into the
underlying Context.
Bug: 181953909
Test: m nothing
Change-Id: I2d9652122bb6387b6b47ca4761e811885d15c2b6
