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
This change uses the order in which mutators are registered at runtime
to define the order in which mutators must be registered in tests to
improve test reliability and prevent issues like bug 181974714.
Generally, it simply sorts the test mutators into the same order as
used at runtime. However, if the test includes a mutator that is not
used at runtime then it cannot sort them because it does not have
enough information to know where it should appear in that order. So,
instead it simply checks the order and makes sure that it matches.
Allowing relationships between mutators to be explicitly defined, e.g.
mutator X should come after mutator Y but before mutator A would fix
that information gap and allow them to be sorted but that is outside
the scope of this piece of work.
The code here is written generically for a sortableComponent as
follow up changes will sort singletons and pre-singletons in the same
way.
Bug: 181953909
Test: m nothing
Change-Id: Ib7d421f578e25f6dccaaff4f73b69838d1b54b00
This separates the collation of mutators from the registration of them
to allow the test infrastructure to sort the mutator order to match
that used at runtime.
Bug: 181953909
Test: m nothing
Change-Id: I01a073289d44417f327b0815c09eb1c033d464f2
In preparation for following changes that will ensure the order of
registration (and so execution) for mutators, singletons and
pre-singletons in tests match the order in runtime this change creates
the sortableComponent interface to allow those to be sorted in the same
way without having to resort to reflection.
By moving the registration code into each component type this change
also eliminates some unnecessary duplication of that code.
Bug: 181953909
Test: m nothing
Change-Id: I597b461b966c84faaeb13e7dff765f1fadd99981
A lot of existing tests that expect errors to be reported do not check
the returned result. This change treats failures of the error handler
in that situation as fatal.
The default error handler already behaved that way. The others did not.
FixtureExpectsAllErrorsToMatchAPattern uses
CheckErrorsAgainstExpectations and it was safe to just make that func
treat any unmatching errors as fatal as all the existing usages are at
the end of test functions.
FixtureExpectsAtLeastOneErrorMatchingPattern uses the
FailIfNoMatchingErrors function which is used in a number of places
(including CheckErrorsAgainstExpectations) that do not want to treat
a test failure as fatal. So, that was modified to return false if no
matching error was found and the error handler treated that as fatal.
Bug: 181070625
Test: m nothing
Change-Id: I6e4df53f93250348bc050d4ff098134e6314ae30
FixturePreparers is a bad name for a method that creates a collection
of FixturePreparers for a couple of reasons:
* Conventionally it would be used as the name for []FixturePreparer if
it is necessary to add behavior to that.
* There are many different types of collection, particularly when order
matters.
Bug: 181070625
Test: m nothing
Change-Id: I55394ff369375dcac2d7b72e4d803a4818762d36
Adds the test fixture support and converts a few tests to exercise the
code and show how it works.
Bug: 181070625
Test: m nothing
Change-Id: I0a2b40fff93b6041f9aa8c4ef0aba91da1bc8bf3
Add a ctx parameter to AndroidMkExtraEntriesFunc to allow them to
access providers.
Test: m checkbuild
Change-Id: Id6becc1e425c3c3d8519248f8c0ce80777fac7cc
Merged-In: Id6becc1e425c3c3d8519248f8c0ce80777fac7cc
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
The previous implementation relied on the implicit registration of Bp2Build mutators, resulting in test non-hermeticity. Refactor bp2build tests to explicitly specify the bp2build mutators under test.
Test: Soong tests
Test: TH
Change-Id: I9b9674bad1ea533b3bd31b07077a9e02c99b4c1d
This CL creates the framework necessary for generating
BazelTargetModules from regular Soong Android modules.
BazelTargetModules are code-generated into Bazel targets in BUILD files.
See the follow-up CL for examples of creating filegroup/genrule
BazelTargetModules.
Test: GENERATE_BAZEL_FILES=true m nothing # creates out/soong/bp2build
with no BUILD files, because there are no BazelTargetModules in the
module graph.
Change-Id: I33a96365bd439043b13af6db9e439592e9983188
