1. The current logic in the rsCppCmdLine only removes the target from the
first intermediated depFile, which is different from the logic in Make, see
https://source.corp.google.com/android/build/make/core/definitions.mk;l=1078
2. The expected logic, as that in Make, is to remove the target from every
intermediate depFile, if there are many, before the concatenation;
3. This bug would cause dependency cycle error, please check the bug number
below for more details;
4. The fix is to make sure the logic here is the same as that in Make.
Bug: 195036632
Test: m CtsRsCppTestCases with the converted Android.bp file (run more than
once to make sure no error occurs)
Test: manually checked the gen/rs/rs.stamp.d file to make sure there
is only one target on the top (the same as that built with the former
Android.mk file)
Test: TreeHugger
Change-Id: If79e3e5e7bc18a6fddcf56c0168daea93726afc6
This hasn't worked for a couple years, and continues to bitrot. Just
remove it.
Adds a bpfix rule so that we can eventually remove the
product_variables.pdk definition, which is now always a no-op.
Test: treehugger
Change-Id: I830b54d419b59f6db1d4617b45e61a78234f57a7
Merged-In: I830b54d419b59f6db1d4617b45e61a78234f57a7
Instead of UnbundledBuild, use AlwaysUsePrebuiltSdks
to determine if java modules needs to be built against prebuilt sdks.
And rename UnbundledBuildUsePrebuiltSdks to AlwaysUsePrebuiltSdks to
express its behavior more correctly.(It can be orthgonal to "Unbundled")
Bug: 160390776
Test: TARGET_BUILD_UNBUNDLED_IMAGE=true m vendorimage
Change-Id: I0be7265c1959d8774c295372cd7a9250169f6df9
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
Instead of having all the object compilations depend on a stamp file,
instead depend on the headers, which are already available in the build
graph.
This allows my RBE builds to just find the headers, instead of having to
walk the graph to find the other outputs.
Test: treehugger
Test: build a system image with RBE
Change-Id: I0a310229be26d7bd399e074a4350d5be038f8661
If a generated renderscript header is referenced by a cpp file
clang will insert a depsfile dependency on the header. If the
generator rule does not include the header as an output, ninja
will not consider the cpp file dirty after the generator runs,
and not rebuild it. On the next build, it will see that the
timestamp of the generated header is new and consider the cpp
file dirty.
Mark the header files as implicit outputs of the generator.
Bug: 75982985
Test: m libstagefright_mediafilter
touch frameworks/av/media/libstagefright/filters/saturationARGB.rs
m libstagefright_mediafilter
m libstagefright_mediafilter
Change-Id: I3ac899322fe9cae2a6e4171092740339ef844494
The system_$(VER) is added for vendor, similar to sdk.
Bug: 67724799
Test: build
Merged-In: I2545c92707591ca278066870c74e9f49e9825855
Change-Id: I2545c92707591ca278066870c74e9f49e9825855
(cherry picked from commit b8baff1fa3)
there's no use case for prepending/appending to bool, and string
properties within module struct. Declearing "*bool" and "*string" almost
cover everything user need.
I did see one case that user specify relative_install_path as
path prefix in cc_defaults, and concatenate with the one in real module
to get the final relative install path in Android.bp <bionic/tests/libs>.
Test: m -j checkbuild
Bug: b/68853585
Change-Id: If3a7a2689c3fc307aae136af6bc9c57f27a1e1a0
Now that android.ModuleContext does not include blueprint.ModuleContext
we can rename android.ModuleContext.ModuleBuild to
android.ModuleContext.Build without colliding with
blueprint.ModuleContext.Build. Leave ModuleBuild as a wrapper around
Build for now to avoid having to update all the users outside
build/soong simultaneously.
Test: m checkbuild
Change-Id: I18eb8cc04faf002049a11d9aac97e9732ff5d638
Descriptions currently look like:
[ 0% 4/29328] cc out-soong/.intermediates/external/clang/lib/Sema/libclangSema/android_arm_armv7-a-neon_denver_static_core/obj/external/clang/lib/Sema/SemaCodeComplete.o
This is not very helpful - most of the characters are used to show the
output path, which contains useful information like target architecture,
but also contains most of the path to the source files twice, and less
useful information like the exact variant name used by soong.
Make the descriptions look like:
[ 0% 3/29329] //external/clang/lib/Sema:libclangSema clang++ SemaTemplateInstantiate.cpp
This is //path/to/module:modulename tool relative/path/to/source/file
Test: builds, looks pretty
Change-Id: I3087aa7d4eb1860ef6239d77407b8b35445616d7
C++ sources generated from .rs files need includes in
frameworks/rs and frameworks/rs/cpp. Add them automatically
instead of requiring modules to add them manually.
Test: builds
Change-Id: I7270fef0b36c1956475d6d83ab8aa2e3c362e688
