With the improved RuleBuilder rsp support a manual resources.list
file is not necessary, use FlagWithRspFileInputList instead.
The switch to RBE support in RuleBuilder in
Iab4e09d961891ef182643583d4d456e413bc5e39 obsoleted tracking remoteInputs
and remoteRSPInputs, remove them.
writeLintProjectXML was written to allow it to be applied to a separate
rule than the one that ran lint, but it is not used that way. Using
the same rule for both means that manual tracking of the input
dependencies described by the project.xml rule but read by the lint
rule is not necessary, just treat them as inputs to the single rule.
Test: m lint-check
Test: m USE_RBE=true RBE_LINT=true RBE_LINT_EXEC_STRATEGY=remote lint-check
Change-Id: If1827b9dede3ebcd0792b6b4b8114d3199f6570b
The lint rule is manually creating a second rsp file because Ninja
only supports on per rule. Move the support into RuleBuilder so
that it can apply the same rewrites that it does to the primary
one.
Test: TestRuleBuilder_Build
Change-Id: Iec250a2d60e74ccf1b4ad085a960fec6867ea559
The current implementation causes inputs listed in an rsp file used with
sbox to be duplicated 3 times in the build.ninja file; once as a
dependency of the rule, once in the rspfile_content field of the rule
with the paths rewritten to be relative to the sandbox, and once in the
rule to write the sbox manifest. When RBE is enabled it also gets a
fourth copy in the list of files to be treated as inputs by rewrapper.
Reduce this to a single copy by using "$in" for the rspfile_content so
that the files only have to be listed in the input dependencies of the
rule, and then add support to sbox to rewrite the rsp file while copying
it into the sandbox, and pass it to rewrapper as well.
Test: m lint-check
Change-Id: I3f46f61119508d39a8bb231c99fc130153fb6f04
Add a test that was dropped in Ic0db961961b186e4ed9b76246881e3f04971825c.
Test: rule_builder_test.go
Change-Id: Idf136919939ad28eb5260dd8d686abe6948f47c7
rewrapper supports a comma separate list of rsp files, replace
REParams.RSPFile with REParmas.RSPFiles.
Test: remoteexec_test.go
Change-Id: I7850c071c23d368d6fad4480dd527d146c13c6d3
sbox is going to need to read and write response files, move ReadRspFile
to its own package.
Test: response_test.go
Change-Id: Iecb5486b4aaeb2531828743ad8ef784df675e18e
TestDroiddoc compares the value returned by OutputFiles(""), which will
usually be absolute paths including the temporary buildDir, against
paths returned from TestingBuildParam.RelativeToTop(), which does not
currently change the Path contents and so will include absolute
temporary paths. However, a follow up change to this will make the
TestingBuildParam.RelativeToTop() also change the Path contents at
which point this test would be comparing relative to absolute paths.
So, this change makes sure that they are all converted to relative to
top paths before comparison.
Bug: 183650682
Test: m droid
Change-Id: Ia4478f527af27a920945f5849525e5031cc5b8b6
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
Revert submission 1594391-bp2build-cc_library_static
Reason for revert: Broke the build on aosp-master
Reverted Changes:
Ib16ccf31a:Add cc_library_static macro to help with bp2build ...
I37c856be2:Add bp2build support for cc_library_static.
Change-Id: Ie94d5bc6da81758cd4e0461c08a810a29643c971
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
Stop including fields in the test name for TestJavaSdkLibraryEnforce to
reduce its length to avoid the filename too long limit.
Test: m nothing
Check the lengths before (~240) and after (~74) to make sure
there was a sizeable reduction.
Change-Id: I275a1110e5102b8ea8376759f28c7c6333a5efee
Creates a new deptag type for it so that it can implement the marker
interfaces that will exclude it from being added to the APEX and from
visibility enforcement. The latter is probably not an issue ATM because
the dependencies are added after visibility checks are enforced but
this code is undergoing lots of refactoring so that may change.
Bug: 177892522
Test: m nothing
Change-Id: Ibd167d557adec761a2e3eed78f4d334c40a04fb9
Also refactor bp2build-related code for cc_library_headers.
Test: Added unit test.
Test: bp2build-sync.py write; bazel build //bionic/... still works (but bp2build is disabled for most cc_library_static targets for other reasons)
Change-Id: I37c856be20a47b154909338a22a7dba1ab55693f
* changes:
Group all the preparations needed for testing dexpreopt
Separate methods used for fixture based and legacy tests
Use more inclusive language in dexpreopt/testing.go
This CL handles updatable boot jars in the same hacky way as we handle
non-updatable boot jars: it creates a set of predefined paths to the dex
jars in a global config, then traverses all modules in a singleton
context, finds updatable boot jars and adds copy rules from these jars
to the predefined paths. A proper way would be to register dependencies
of the dexpreopted modules on the boot jars and extracting paths to dex
files by walking these dependencies.
Bug: 178467404
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Test: added new Soong test
Change-Id: I87f764109315f79315d73bf43799b70eb010fc0b
Previously, soong.environment.used was written after build.ninja and if
the amount of time that passed between the two was long enough, Ninja
would decide that build.ninja is older than soong.environment.used and
rebuild it.
Test: test_null_build in bootstrap_test.sh in a loop.
Change-Id: I5467da487e8e8f2646644b8a7fb9549b9ff18276
Make it easier to test dexpreopt functionality by grouping all the
fixture preparations together.
Bug: 177892522
Test: m nothing
Change-Id: I94f66e3ec82efc4fd791f4fdab678d298565e452
The fixture mechanism makes it easy to refactor by splitting up an
existing preparer into separate ones and then combining them back
together. Unfortunately, that becomes slightly more tricky when
preparers and legacy tests use the same functions to register build
components and define default modules.
This change splits the RegisterRequiredBuildComponentsForTest and
GatherRequiredDepsForTest methods into two methods each, with the
existing method used for legacy tests and calling the new method that
is used for the preparer.
At the moment all the functionality is in the new methods but over
time, as functionality is extracted into separate preparers, the
functionality can also be moved from the method that is common to both
legacy and fixture based tests into the legacy only method.
Bug: 177892522
Test: m nothing
Change-Id: I233a4fe1fb072a00292acc2bb20821ec82a9bd67
