This property was introduced for inter module dependencies in the
prebuilt module sdk. https://r.android.com/3252814 changed the visibilty
of all prebuilts in module sdk to //visibility:public. This property is
a noop now, and can be removed.
Test: go test ./sdk
Bug: 365111645
Change-Id: I186a201895fc2b33a65bbedae8a8326e087feb2b
I'm going to be adding some methods to this interface, give it
a name based on how it's going to be used, not based on what methods
it contains.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I9bba04ba756c4dbe00625e2d04af81e78a11cae9
If you remove a folder that's part of a glob, soong will error out
currently. Instead treat it like an out-of-date dependency.
Bug: 364749114
Test: m nothing, rm glob folder, m nothing
Change-Id: I86ee755a0815b79192133223f8ef3ecd90669db1
https://r.android.com/3252814 modified the visibility to
//visibility:public to account for visibility skew between development
and release branches.
Drop the comment about stub libraries being safe to use by any _rdep_.
There might be cases where this is not true.
Test: N/A
Bug: 239189932
Change-Id: I74ca661a40384d480148f5e18f76495e837c58e3
This reverts commit b1fbc79206.
Removing the build broken flag to progress the python3 migration. It's been here for over a year and I haven't heard of any users.
Bug: 203436762
Test: Presubmits
Change-Id: Icfd2d25986abda934c60fd868ed5525dc384fbf3
It's been available for over a year, lets progress the python3 migration
by removing it.
Bug: 203436762
Test: Presubmits
Change-Id: I46a6477ec65e98b7e6df5cc1359f676dcbd0f08e
Previously, globs worked by having soong_build rewrite a ninja file
that ran the globs, and then dependended on the results of that ninja
file. soong_build also pre-filled their outputs so that it wouldn't
be immediately rerun on the 2nd build.
However, the pre-filling of outputs worked for ninja, because although
it updated their timestamps, the soong ninja file was then touched
by soong_build after that, so the soong_build ninja file was newer
and ninja wouldn't rerun soong. But N2 reruns actions if their inputs'
mtimes change in any way, not just if they're newer. Similarly,
hashed-based ninja implementations could not enforce an order on
file contents, so they would have the same problem.
To fix this, lift the glob checking out of ninja and into soong_ui.
Soong_build will output a globs report file every time it's run, and
every time soong_ui is run it will check the globs file, and if any
globs change, update an input to soong_build. soong_ui is essentially
doing what was done in ninja with bpglob actions before.
Bug: 364749114
Test: m nothing, m nothing again doesn't reanalyze, create a new file under a glob directory, m nothing again reanalyzes
Change-Id: I0dbc5ec58c89b869b59cd0602b82215c4972d799
The zeros were kept in place of the timestamp in case people were
parsing it. Let's try to remove the zeros now and see what breaks.
Test: Presubmits
Change-Id: Ic52168f6be05a74323d8e47935de5c6a5cf15516
It's now taking advantage of the uses_order_only_build_number_file
feature of genrules, and doesn't need to be excempted from sandboxing.
Bug: 307824623
Test: Presubmits
Change-Id: I6ae5da7518990fbf4083aeac1aaba770210a4be1
aosp/3255916 didn't add all of the required infrastructure.
Refactor it to be more like x86_64 so it requires less
boilerplate code.
Bug: 364383722
Test: presubmit
Change-Id: Idc5279ffc5fe964bea9f98873c01468944d90091
Ravenizer and the other rules that modify the output jar also need to
replace the implementation jar depset with the modified output jar.
Bug: 308016794
Test: atest CtsOsTestCasesRavenwood
Flag: build.RELEASE_USE_TRANSITIVE_JARS_IN_CLASSPATH
Change-Id: I87ec143431c09ed878f8e1c3541b56d8077e23b5
There are two versions of aosp extservices - one for Tplus and one for
Sminus. When prebuilts are active, the `contents` validation of both
variants of extservices bootclasspath fragments should be disabled to
account for BCP jar skew.
This CL adds ApexAvailableName to ApexInfo to achive that. If an
api_domain matching the ApexAvailableName has been selected in
`all_apex_contributions`, the source apex variants will be disabled.
Bug: 361771739
Test: lunch cf_x86_64_phone-next-userdebug
Test: m nothing with ag/28851886
Change-Id: I505a7ad8295c258e2eeef7f183669f7a75a1c88e
... if prebuilts are selected.
This is a special case of b/361771739 where a apex starts contributing a
jar to the BCP. `disableSourceApexVariant` uses
`PrebuiltSelectionInfoProvider` and this gets populated via the
following dep chain
```
source --> prebuilt --> all_apex_contributions
```
This runs into issues if a prebuilt bootclasspath_fragment does not
exist.
This CL creates a dependency edge between the source module and
all_apex_contributions singleton module so that
`PrebuiltSelectionInfoProvider` is available for
`disableSourceApexVariant`
Bug: 361771739
Test: lunch cf_x86_64-next-userdebug
Test: m nothing with ag/28851886
Change-Id: I92d88199a27579d3c9879d40fd354653370efcce
I'm rewriting how globs work in soong to make them compatible with
hash-based ninja implementations. As part of this, I'm removing this
unnecessary usage of globs to make them simpler.
In this case, since we're already globbing the directory at analysis
time and causing soong to rerun, we can ensure the aapt2 action also
reruns by putting a hash of the glob results onto the command line.
Bug: 364749114
Test: m framework-res, touch frameworks/base/core/res/assets/test1.txt, m framework-res rebuilt framework-res.apk, rm frameworks/base/core/res/assets/test1.txt, m framework-res rebuilt framework-res.apk again
Change-Id: I4f666367a9a0fd0dfa42dc51ef3a788a02b41747
This commit adds the libbpf_prog soong module which is heavily based on
the bpf soong module. Due to issues encountered and concerns around
compatibility and testability of mainlined bpf modules, support for
libbpf is added as a separate module.
Specifically, when changing the bpf module from
InitAndroidArchModule(... android.MultilibCommon) to MultilibFirst, the
soong apex bpfs functionality breaks. We have not identified a good
mechanism to fix this, and as we would then be creating architecture
specific bpf program binarys, additional testing and infrastructure
would be required.
It should be noted that libbpf_prog should not be used for features
which target 32bit kernel architectures at this point, as we do not
have a mechanism to identify the kernel arch at build time. I.E. 32bit
userspace could be on either 32bit or 64bit kernel arch, and we require
arch specific includes (vmlinux.h). Therefore, we default to 32bit
userspace on 64bit kernel to match the precedence set with the legacy
bpf programs.
Example use:
libbpf_prog {
name: "xyz.o",
srcs: ["xyz.c"],
arch: {
arm: {
local_include_dirs: ["vmlinux/arm64"],
},
arm64: {
local_include_dirs: ["vmlinux/arm64"],
},
x86: {
local_include_dirs: ["vmlinux/x86_64"],
},
x86_64: {
local_include_dirs: ["vmlinux/x86_64"],
},
},
}
Bug: 359646531
Test: manual
Change-Id: Ie58515d70abee061470cf4bb803228e00d496ac3
Signed-off-by: Neill Kapron <nkapron@google.com>
The soong primary builder action lists all the Android.bp files
as dependencies via a depfile. The top-level one doesn't need to be
listed as an input explicitly. I think it was there from the early
days of soong when soong started at the top-level Android.bp file and
traversed downwards through references via the subdirs or
optional_subdirs variables.
Bug: 364749114
Test: Presubmits
Change-Id: I72eabe4d4179696bfa258c8c4c56351a132e0870
