Revert submission 1366377-prebuilt_build_tool_make
Reason for revert: breaks build
Reverted Changes:
I20bf062bb:Export prebuilt tools to Make
I4bb526492:Move some prebuilt build tool configs to Soong
I195b68813:Support per-module MakeVars
Ibcb257e7b:Fix dependency loop with flex
I6150f0f39:Switch cc's use of bison and flex to prebuilt_buil...
I6939451b8:Reland "Use genrules to build a consistent awk."
Idee60640f:Add prebuilt_build_tool modules for genrule use
I00893172b:Rename bison to bison_bin
I82c26be1c:Add prebuilt_build_tool to allow genrules to use p...
Change-Id: I1ca553ffe4b09250a441b9bc477c3ba98c6f6549
generated_sources needs exclude_* just like that srcs needs exclude_srcs
to support variant-specific exclusion of source files.
Bug: 159585065
Test: m
Change-Id: I49e49b0b3a0115a01fc9cf6f9fe74b23e723a785
Bug: 152482542
Test: m checkbuild
Change-Id: I6175d7c59734ba9b6c32457e5a9b0704d49f4106
Merged-In: I6175d7c59734ba9b6c32457e5a9b0704d49f4106
Exempt-From-Owner-Approval: approved in other branches
(cherry picked from commit e3ce0ba781)
This reverts commit e68926d4d3.
Reason for revert: breaks build in various -plus-aosp branches
Bug: 158293810
Change-Id: I80572f673df83161be02873b2b2acf4b2ba9a2d4
Exempt-From-Owner-Approval: revert
The macro is required only for apex variants regardless of useVndk.
Before the enforcement of LLNDK sdk version, the macro was not passed to
vendor variants.
Bug: 151689896
Test: TARGET_BUILD_APPS=com.android.media.swcodec m
libbase in swcodec apex is linked with liblog#29
(compiled with __ANDROID_SDK_VERSIO__=29)
Change-Id: I57fa4afe027eb39b98bd94d534be9ebe11713f19
sdk_version is passed for relevant variants.
If not specified or "current",
it maps to "10000" for platform variants, and
"min_sdk_version" of the apex for apex variants.
Bug: 150860940
Test: m (soong test)
manually check build.ninja
Change-Id: I5102ab0c5086b5ad29d16ac45af55d32062167b4
This is rarely used feature but cost alot for the local build and build
inra.
Bug: 150506627
Test: m
Change-Id: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
Rename the two prefix-in-list funcs so that their usages are clearer.
Also find and replace all the code that essentially does either.
This introduces additional loops in some places, but I think the added
readability and simplicity outweighs the performance degradation, which
should be negligible anyway.
Test: m nothing
Test: TreeHugger
Change-Id: I37e2276ca0c815105ed0031f23c0b1264b480e4f
For VNDK snapshot and SDK snapshot, deps files have been used to capture
generated headers. But exported deps might contain intermediate phony
files instead of actual header files, which are for optimization of
ninja. To correctly capture all headers, exported generated header files
are gathered separately.
Bug: 65377115
Test: m nothing
Change-Id: Ia03fa69186490a818578190e3c0bfb0261d1fd6e
Exclude vendor/ and hardware/ from the manually written binder interface
whitelist.
Bug: 136279235
Test: interfaces in excluded directories are not checked against whitelist.
Change-Id: I0d640e23489b37d0c0787d5fca6bcdab10034109
Some of the warnings are too common to fix/opt-out for non-Google
projects.
Also in the change, minor clean up of duplicated code.
Test: presubmit
Bug: 139945549
Change-Id: Ic176ef1f17133405851a79592b6bef5ccb403bd9
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
__ANDROID_APEX__ was defined with the name of apex module.
-D__ANDROID_APEX__=com.android.foo
But in this way, conditional compilation is not easy since comparing
macro's string value is not supported in C/C++.
(There's no usages of this value in source tree.)
In most cases, modules can check if __ANDROID_APEX__ is defined to see
if they are compiled for apex.
For modules which should behave differently according to which apex they
are included, they can check __ANDROID_APEX_<NAME>__.
Bug: 142582178
Test: m (soong tests run) && boot device && TH
Change-Id: I0f5e3e9463ccd96cbba333a8bdd648470c5c912d
With __ANDROID_APEX_<NAME>__ definition, native modules may have
different behavior when it is built for a specific apex module.
Previously, the name is passed as value of definition __ANDROID_APEX__
like -D__ANDROID_APEX__=com.android.foo. But it is difficult to do
conditional compilation with it.
Now, since the name is incorporated into definition itself, it gets
easier to set #ifdef condition.
Bug: 142582178
Test: m (soong test added)
Change-Id: I3c90c789fa692a19addf2e5a7c8d4cc571cde112
The NDK is built like this. Having it for app builds within the Android
build system allows us to distinguish platform code from app code.
This is specifically to distinguish AIDL interfaces using libbinder_ndk.
'myBinder-ndk_platform' libs will use additional functionality that
'myBinder-ndk' libs won't use (in the future, these may be separate
variants with the same name, see b/121157555).
Bug: 136027762
Test: using this to distinuish code in NDK vs platform code
Change-Id: I4de6f2e066982e7573ffd28cda44407d9e5648e4
Clang derives the value of __ANDROID_API__ from the triple these days. In a
future version of clang I plan to start making the behaviour of the HWASAN pass
dependent on the API level in the triple, so it's going to need to be accurate.
Test: walleye-userdebug boots
Change-Id: Ie5e36b5c8f6dcda084cc12b1160abbdf94765174
.sysprop files are intended to be used only with sysprop_library, and we
can prevent build error by specifying dependencies upon CreateModule.
Bug: 131708148
Test: 1) try building sysprop_library module.
Test: 2) see liblog is correctly linked.
Change-Id: I702cedc255ee0b6a30c15e474dd6a88d9607b145
So that <module>/gen/yacc/... is (re)created by a single rule, previous
files are removed, and location.hh is in the build graph when it is
produced.
Test: treehugger
Change-Id: I2f6e47ea07f315e10ae1cb8ad50697e7123d0285
Add a proto.plugin property to allow specifying a custom protoc
plugin to generate the code.
Fixes: 70706119
Test: m am StreamingProtoTest
Change-Id: I1ecdd346284b42bbcc8297019d98d2cd564eb94c
libbase dependency is not really needed, but it has been causing build
failure while linking with static variant of sysprop_library. This cuts
the dependency and only depend on libbase_headers and liblog.
Bug: 129301987
Test: 1) flash and boot walleye
Test: 2) try to build various properties with sysprop_library.
Test: 3) sysprop_test
Change-Id: I027e01c754b782818f52103184301267d4cdd576
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
Follow the change to blueprint to make *Escape take and return a string
and add *EscapeList that take and return slices of strings. Fix up
a few places that were unnecessarily converting a string to a slice
and back to a string.
Test: m nothing
Change-Id: I3fa87de175522205f36544ef76aa2f04aef1b936
Add an opaque OnceKey type and use it for all calls to Once in
build/soong. A future patch will convert the arguments to
Once* to OnceKey once users outside build/soong have been updated.
Test: onceper_test.go
Change-Id: Ifcb338e6e603e804e507203c9508d30ffb2df966
A module can be built multiple times when it is referenced from one
or more APEXes. Sometimes, it is required for the module to behave
differently depending on the context; e.g., do A when built form
APEX M, do B when built for APEX N, and do C when built for platform.
The idea is to have a macro __ANDROID_APEX__ which is set to the
name of the apex that the module is built for. It is undefined when
the module is built for platform.
Bug: 122714993
Test: m (apex_test amended)
Change-Id: I11a89c6a0e799f4810194de7ef9ee472a71ca498
Not all projects can be built when their base directory (the
directory containing the Android.bp file) is automatically included.
For example, external/jsoncpp has a file named version, which will
override the standard library's <version> header.
It would maybe be reasonable for this to be on by default, but many
projects in the tree currently depend on this behavior.
Test: make checkbuild
Bug: None
Change-Id: I58dff2689270ae56fef7cf83be31262d16794fc4
From now on, a c++ shared library can be built only with adding
".sysprop" description file to srcs. Sysprop library generator will
automatically generate a .cpp and .h files, and the header file will be
exposed to any clients linking against the shared library. For the full
schema of description file, see system/tools/sysprop/sysprop.proto.
Bug: 80125326
Test: 1) write a .sysprop description file.
2) create cc_library_shared and add description file to srcs.
3) create another module, link against library of 2), include generated
header, and access generated sysprop functions
4) see compile succeeded.
Change-Id: I95005a0724aeb8f11a856b7aee92787a16a5374d
Clang is always used now, so we can remove all the GCC checks. Removing
GCC-specific configuration will happen in the next CL.
Test: m
Change-Id: I4835ecf6062159315d0dfb07b098e60bff033a8a
Recovery variant of a module is now by default built with
-D__ANDROID_RECOVERY__, thus eliminating the need to define a custom
macro to conditionally compile the module for the recovery mode.
(Of course, they can define their own macro if needed)
Bug: 63673171
Test: m -j
Change-Id: I1d1b990329793472b93c2f56080e72d690eef9ec
Every time the toolchain adds a new warning, we had to suppress the
warning in every external projects that violates it, or disable it
globally -- which we end up doing most of the time since the first
option is way too time consuming.
Add a separate cflags option for external projects and move existing
-Wno-* flags there so that we can enforce better code quality for
internal projects.
TODO: Move more -Wno-* flags to ClangExtraExternalCflags
Test: m checkbuild
Change-Id: If3dee491616a1e7ba6223c2f522d100e10c5ee76
There was a bug that recovery.cflags is ignored. Respect the property
when building for recovery.
Bug: 79146551
Test: m -j
Change-Id: I24c1c1b593c83eb1992721571c6d5c42483a41a0
`recovery: true` installs a module to the recovery partition.
`recovery_available: true` makes a module to be available to other
`recovery:true` or `recovery_available: true` modules.
These to are very similar to vendor, vendor_available properties, except
for the target partition.
Bug: 67916654
Bug: 64960723
Test: m -j, toybox_recovery is installed to the recovery/root/sbin
Change-Id: Iaebe0593de16c69fa70de251a61f4d018a251509
ExpandSourcesSubDir was calling SourceFileProducer.Srcs(), and then
doing:
moduleSrcs = append(moduleSrcs[:j], moduleSrcs[j+1:]...)
This modifies the backing store of the slice, which may affect the
original data stored in the SourceFileProducer. Make all Srcs
implementations return slice that points to a copy of the backing
array.
Test: m out/target/common/obj/PACKAGING/checkpublicapi-current-timestamp
Bug: b/76179848 b/76397326
Change-Id: I2432ce196984814daafc5aa9a2746e81de74494c
When building vendor modules with BOARD_VNDK_VERSION=current, the
API of the vendor modules will be current PLATFORM_VNDK_VERSION.
__ANDROID_API_FUTURE__ will be used as before if the version is a
CODENAME.
If BOARD_VNDK_VERSION is not "current", that means the VNDK version
of the vendor modules is BOARD_VNDK_VERSION.
Bug: 74833244
Test: Build and check boot.
Change-Id: I383c76a36101e39c70575b463880b52d3e9d90bb
