This probably got broken by aosp/1609473 because soong_build is now
invoked in two different ways:
- By its absolute path during building out/soong/build.ninja
- By its path relative to the source root when generating documentation
Bug: 182347000
Test: Manual (the long incantation on b/182347000)
Change-Id: I0a3a97e4865ffde4a450a3f7baf3980b5a2016c8
* changes:
Support test fixtures in sh package
Support test fixtures in bpf package
Support test fixtures in cc package
Add temporary RunTestWithConfig method to simplify migration
Support test fixtures in etc package
Convert license tests to use test fixtures
As part of the work on the new fixture mechanism some of the TestHelper
functionality was moved into the android/fixture.go package. This moves
the rest and removes the now duplicated TestHelper from the sdk
package.
Also removed some unnecessary & operators.
Bug: 181070625
Test: m nothing
Change-Id: Ia09a5d05e4fab3a4e28cf44b2d947a33541e3925
The old error message was wrong because this message is emitted
specifically when a non-hermetic tool is not found.
Test: Manual ("m nothing")
Change-Id: I857c1c2bb059aff894e8bd3dd0c09b030c82035d
They should have had `android:"path"` tags attached so that users can
point them to filegroup modules.
Test: app_test.go & app_import_test.go
Bug: 182175153
Change-Id: I5580408488ffe5fc12c869cbfb7a468713dcbc96
Used to exercise the new functions to allow the env configuration of a
test fixture to be customized.
Bug: 181070625
Test: m nothing
Change-Id: Iea1d7b20498d690fcade4b6699a70773ea9175c2
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
In addition, make the Ninja command nicer by using backticks instead of
backslash-quoting double quotes.
Test: Manual: "m queryview"
Change-Id: I5d6e1d41424e0229bfe08e2e7eaf2fb025ed48c2
Because OverridablePropertiesDepsMutator is run after prebuilt_postdeps,
prebuilt's replacement doesn't affect to those deps added by overridable
properties.
By running prebuilt_postdeps again after
OverridablePropertiesDepsMutator, replacing source with prebuilts is
applied to those deps.
Bug: 152155285
Bug: 181953909
Bug: 181974714
Test: m nothing
Change-Id: I24acc02785c9580c2beca096042f1173eb28ba9a
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
* changes:
Separate the collation of singletons from registration
Defer registration of singletons and pre-singletons in TestContext
Ensure mutators used in tests are in the same order as at runtime
Previously, there was a bug that caused tests which ran successfully on
their own to fail when run together in parallel. They each extended the
same factory and ended up sharing the preparers slice which meant that
they overwrote each other's preparers causing the tests to fail.
This change fixes that by creating a new slice for each factory.
Bug: 181070625
Test: m nothing
Change-Id: If340c125c5b03a9d5c36a59ff4da4ec189808f9b
That is to allow the order in which singletons are registered at
runtime, including the ones added by default, to be used to define the
order in which singletons must be registered in tests.
Bug: 181953909
Test: m nothing
Change-Id: I22f90c90100a8d52a572d4451a1a5d256784b57a
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 got broken by aosp/1610785 which changed the assumptions
soong_build makes about its environment.
At that time, I didn't know that queryview also invokes soong_build
through another pathway.
Test: Manual: "m queryview && m nothing"
Change-Id: I06ed42aee0d97e18f634eeeaca37108009b29d78
This works by setting the SOONG_UI_DELVE= environment variable to the
port on which soong_ui should accept a Delve connection on.
This is achieved by reusing the Delve execution logic between soong_ui
and soong_build.
Test: Manual.
Change-Id: Id2c1d4b6faac1a4a3918c91030ce2239f7daf54f
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
