Using bpf as test data installs the module into a strange
subdirectory, clear the Rel() value before exporting it as
a SourceFileProducer.
Bug: 130206035
Test: m vts_test_binary_bpf_module
Change-Id: Ifdae90d11b15d65c097562d7d6985a8a1dca2bfd
Merged-In: Ifdae90d11b15d65c097562d7d6985a8a1dca2bfd
(cherry picked from commit 0adfee5a20)
Move the logic from ctx.ExpandSources into android.PathsForModuleSrc
and ctx.ExpandSource into android.PathForModuleSrc, and deprecate
them. When combined with the pathDepsMutator this will let all
properties that take source paths also take filegroups or genrule
outputs, as long as they are tagged with `android:"path"`.
Test: All soong tests
Change-Id: I01625e76b5da19240e9649bf26a014eeeafcab8f
Add `android:"path"` to all properties that take paths to source
files, and remove the calls to ExtractSource(s)Deps, the
pathsDepsMutator will add the necessary SourceDepTag dependency.
Test: All soong tests
Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
All BPF programs need helper header files. These end up being
duplicated. Let us add a path to the common BPF helper to the search
path so that it can be used across projects.
No functional change to the final system image, only a build change.
Bug: 122665156
Change-Id: Ieee838df98258213efa24d74a12e069f056c66c1
Signed-off-by: Joel Fernandes <joelaf@google.com>
This allows other modules depend on bpf object outputs via the data
property.
Bug: 120246361
Test: bpf_test.go
Change-Id: I2ba9b9fea4d60f896d16f34053eb04513eae30ea
Add a module type for compiling .c to .o using clang --target=bpf.
Bug: 72981744
Test: m
Change-Id: Ie5712bfabe34901a84ed33737053306ca56ebeb4
Merged-In: Ie5712bfabe34901a84ed33737053306ca56ebeb4
(cherry picked from commit 3ba736a7e1)
