gen_ltp_config used to read files from the source tree,
but this cl refactors it to package all the files it
needs into the tool itself, so it's more hermetic and
all the genrules don't need to explicitly list the files
the tool needs.
go/roboleaf-busy-beavers-sandboxing
Bug: 307824623
Test: diff'd the files produced by the ltp_config_* genrules before/after this change
Change-Id: Ia72084965dcb8659394068b7c6877adb1c882dc2
With the other cls in this topic, the modules build with sandboxing.
They still fail the genrule_sandobox_test.py because their builds are
non-deterministic though. I wasn't able to find the cause of the
non-determinism, so relying on presubmits to make sure nothing breaks.
Bug: 307824623
Test: m com.android.apex.test.bar_stripped com.android.apex.test.baz_stripped com.android.apex.test.foo_stripped com.android.apex.test.pony_stripped com.android.apex.test.sharedlibs_generated com.android.apex.test.sharedlibs_secondary_generated with sandboxing enabled
Change-Id: I4006732bf1ba08e846dee2e18d89dbf45f2cd7ba
These modules actually work fine with sandboxing, they were just added
to the list because they have non-deterministic outputs, which caused
the genrule sandboxing script to think that sandboxing affected their
outputs.
Bug: 307824623
Test: ./build/soong/tests/genrule_sandbox_test.py UpdatableSystemFontTest_NotoColorEmojiV0.sig UpdatableSystemFontTest_NotoColorEmojiV0.ttf UpdatableSystemFontTest_NotoColorEmojiVPlus1.sig UpdatableSystemFontTest_NotoColorEmojiVPlus1.ttf UpdatableSystemFontTest_NotoColorEmojiVPlus2.sig UpdatableSystemFontTest_NotoColorEmojiVPlus2.ttf with aosp/2816385
Change-Id: I07b1df779c8d47ad875a4fc2d3af5e46945cff83
The denylist was built by running `genrule_sandbox_test.py` on all
modules in the tree. `genrule_sandbox_test.py` checks that the sandboxed
genrules build, but also that they get the same results as the
unsandboxed version.
In this case, the genrule actually builds with sandboxing just fine,
but they have non-deterministic results, which caused
`genrule_sandbox_test.py` to think that they didn't work with
sandboxing.
Test: m com.android.apex.apkrollback.test.pem com.android.apex.apkrollback.test.pubkey com.android.apex.cts.shim.debug.pem com.android.apex.cts.shim.debug.pubkey com.android.apex.cts.shim.pem com.android.apex.cts.shim.pubkey com.android.apex.cts.shim.v2_no_pb com.android.apex.cts.shim.v2_signed_bob com.android.apex.cts.shim.v2_signed_bob_rot com.android.apex.cts.shim.v2_signed_bob_rot_rollback com.android.apex.cts.shim.v2_unsigned_apk_container com.android.apex.cts.shim.v3_signed_bob com.android.apex.cts.shim.v3_signed_bob_rot com.android.apex.cts.shim_not_pre_installed.pem com.android.apex.cts.shim_not_pre_installed.pubkey com.android.apex.rotation.key.bob.pem com.android.apex.rotation.key.bob.pk8 com.android.apex.rotation.key.bob.rot com.android.apex.rotation.key.bob.rot.rollback com.android.apex.rotation.key.bob.x509.pem com.android.overlaytest.overlaid.pem com.android.overlaytest.overlaid.pubkey com.android.overlaytest.overlay.pem com.android.overlaytest.overlay.pubkey
Change-Id: I950767449025163d8c71bb5a7b2e2f15a1ce4a84
Contingent on aosp/2788322
Test: GENRULE_SANDBOXING=true m libperfetto_client_experimental # bit
identical
Change-Id: I885f420850a165f042b94685e7cf1215d5620716
I'm not sure how this was missed earlier.
Bug: 290816499
Test: build/soong/tests/genrule_sandbox_test.py -t sdk_phone_x86_64 all with aosp/2666142
Change-Id: I8d21a34e3b13ac568fa6153a31c43ba3e4d516bd
These were added with the android 14 release.
Bug: 290816499
Test: run genrule_sandbox_test.py with a local change to check all genrules in the tree
Change-Id: Icf3627c245638ab3f73b83e24ef04c916d7ab58b
Bug: 290816499
Test: run genrule_sandbox_test.py with a local change to check all genrules in the tree
Change-Id: Id18b801c2306dd59b5b593b004b513b578ce3705
This no-op refactoring facilitates some upcoming functional changes for
"bp2build allowlist v2". The work requires that the bp2build conversion
mutator be changed from a TopDown mutator to a BottomUp mutator.
Refactoring all bp2build-related methods so that they use Bp2buildMutatorContext
makes it easier to make this functional change without touching tens of
files and multiple projects.
Bug: 285631638
Test: m bp2build
Change-Id: I3d1ef3064146e959c6f0dc315350fc9764bf2bd2
Instead, we return an error. This allows us to access some product
variable information earlier when it will not be used as an attribute
without panicing
Test: m nothing
Change-Id: Id094b2b9e1364a8d174d99b3824fa149fb235b3e
According to go/roboleaf-busy-beavers-sandboxing, this field should just take in any data files needed by the tool. The existing description makes it sound like this property should only contain a single file that will be used as the tool itself.
Change-Id: I3ef3b8ceb52f7a7e6de9e0a897d5cc05c9c2d336
So that users can use soong config variables / product variables
to adjust a genrule's command.
Bug: 295910468
Test: m nothing
Change-Id: I9fedf8d5d52e515c3fdb913411ce1b3fecb7ba81
If `srcs` contains a gensrcs/genrule module, the current bp2build module
will put it in the catch-all `srcs` attribute. This is reserved for .cpp
sources, so if the genrule produces a .proto/.aidl/... file, this will
fail.
This handles genrules that produce .proto files. To implement this, this
creates an additional partition that detects if the other module is a
genrule/gensrc that produces .proto files. If true, it will append it to
the proto partition.
This CL does not handle
- genrule that produce .c/.aidl/.yacc/.... files. They will continue to
be partitioned into the catch-all partition
- java modules
Test: unit tests
Test: TH
Bug: 293205700
Change-Id: Ib720fdf3a053ff5dd256e6faa632e3fa7776966d
Embedding multiple includes from a genrule may be difficult to read,
instead we generate a header library that contains the headers and all
include dirs that Soong generates.
Test: go test bp2build tests
Change-Id: I590c74c133f015f27cccf5a2fd916153ad9c125e
Bug: 290816499
Test: run genrule_sandobx_test.py with a local change to check all genrules in the tree
Change-Id: I258fe11640c71d532ef48ed88270dec72bd69814
Previously, genrule export_include_dirs always added ModuleDir to
exported include dirs when export_include_dirs is set but not when
export_include_dirs is not set. Now when export_include_dirs is set, we
also export the directory without the additional ModuleDir subdir.
Test: genrule go tests
Test: set export_include_dirs and test
Change-Id: I46e860b2c20c1a96bddd14367d7fa737d901994d
When "write_if_changed: true" is set, it will call restat for ninja.
With this option the output file will be copied only if it is changed.
Bug: 290130959
Test: ninja rule include "--write-if-changed"
Change-Id: I8bd77b43b22eb0115e0bdc73718b2d6997d92652
With the other change in this topic,
`OpenwrtControlServerProto_h` and
`OpenwrtControlServerProto_cc` both successfully build with sandboxing
on.
Test: build/soong/tests/genrule_sandbox_test.py --show-diff OpenwrtControlServerProto_h OpenwrtControlServerProto_cc
Test: GENRULE_SANDBOXING=true m OpenwrtControlServerProto_h OpenwrtControlServerProto_cc
Test: GENRULE_SANDBOXING=true m droid
Change-Id: Id56824ed935e1d16d2333e5a1aeac248cdfcaeb6
This enables sandboxing for inputs that are necessary but do not need to
have a source file generated.
Test: GENRULE_SANDBOXING=true m framework-javastream-protos \
framework-cppstream-protos
Change-Id: Id5ca1dab5799c25fa96b564a7d2008c2e7b5382b
Soong does not enforce apex_available on the contents of test apex. To
prevent special-casing test apexes in the apex validation aspect in
Bazel, drop the test apexes from the tags altogether.
( The core problem I am trying to solve is making sure that stub
libraries in Bazel have a single apex available. apex validation happens
to be a nice side benefit)
Bug: 277651159
Test: go test ./bp2build
Change-Id: Ibb3cfedb5c0f2cda0464bf3758c70b67cb5885d1
Also disallow arch variant of genrule.out.
This is to be consistent with bazel where we are migrating to.
Bug: 254114674
Test: Manual
Change-Id: I685a2e64102b7bb68128b39931f0bc85878bc6de
When gensrcs's srcs prop is set with filegroup from external package and especially when gensrcs generates cpp headers, it's not trivial to know what the output paths and their correponding include paths look like.
In mixed build, there are a few bugs in gensrcs's include paths for cpp headers (b/248555356 and b/248554581) that we'll eventually need to fix. These tests serve as an documentation of the existing behavior when gensrcs generate cpp headers.
Test: go test
Bug: 248555356
Change-Id: I10168dd4229be8f110a31955d214ef792c8050de
