-fdebug-default-version=5 is causing $TMPDIR to end up in the dwarf
debug data, which causes the buildbot results to be nondeterministic.
Pass -fdebug-default-version=4 for assembly files as a workaround.
Bug: 235105792
Test: lunch aosp_arm-userdebug && m libbase && llvm-dwarfdump --debug-line out/target/product/generic/symbols/system/lib/libbase.so
Change-Id: Ife04e3c898bbb1291f71b8365fbca854cd2d2b66
MODULES_ADDED_WALL is deceiving and it actually meant which modules are
allowed to have warnings (do not automatically append -Werror flag).
Test: presubmit
Bug: 233183337
Change-Id: Ibd21e269eba04d01f13026d70a9e34ccb1cf26d7
We set -Wall in the global cflags, and then again at the point where we
decide whether or not to add -Werror. The trouble with this is that it
undoes the effect of any attempt to disable a warning implied by -Wall.
Discovered while trying to enable -Wmisleading-indentation (which is
part of -Wall) in a way that doesn't apply to external/ or vendor/.
Test: treehugger
Change-Id: I68d74fb05922dd9f6bd4c8423ca69b485c15e3d2
Similar to `tidy_disabled_srcs`, a `tidy_timeout_srcs` list
can be used to include all source files that took long to compile
with clang-tidy. Files listed in `tidy_timeout_srcs` will not
be compiled by clang-tidy when `TIDY_TIMEOUT` is defined.
Bug: 201099167
Test: TIDY_TIME=90 make droid tidy-soong_subset
Change-Id: Ie0bfda66caae4445d10117ceefa1b5b8c1ecf256
There is no easy way to inform C++ targets whether they're building "not
in normal Android". In the past we used __ANDROID_RECOVERY__, but this
isn't defined for ramdisk targets, or for vendor_boot. Furthermore
there's no "target.ramdisk.cflags" option to add it.
Add a new __ANDROID_RAMDISK__ define that will be set in any ramdisk or
recovery target (since recovery by definition is in a ramdisk).
Bug: 205987817
Test: mm bootimage, vendorbootimage, recovery
Change-Id: If3cd34b07fe0e20abc5108cb338a56698d33e42e
* Only prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/x86_64-w64-mingw32/bin
exists for x86_windows_host.
* Remove config.ToolPath;
add required -B flags into ToolchainCflags and ToolchainLdflags.
Bug: 218883919
Test: make droid tidy-soong_subset
Change-Id: I9a18bf8cc0cf84e091c7463b3bda316eaab53aa3
* make tidy-soong_subset, or make tidy-<any_directory>,
should trigger the same clang-tidy compilations
with or without global WITH_TIDY=1.
* Normal make should not trigger clang-tidy compilations
unless global WITH_TIDY=1 or a module has set tidy:true.
Bug: 213918926
Test: NINJA_ARGS="-n" make tidy-soong_subset
Test: NINJA_ARGS="-n" make <some-library>
Change-Id: Iafffd3894abe137c9584c2c01830898422f9a677
* shared libraries and binaries can depend on NDK share libraries
Bug: 208310402
Test: WITH_TIDY=1 make tidy-soong
Test: WITH_TIDY=1 make droid
Change-Id: I88ca8555c62d5ca49e36ca089749722166afec30
cc/java modules can have .aidl files as srcs. Pass min_sdk_version to
the aidl compiler so that it can check some features against it.
For example, ParcelableHolder AIDL type is available since 31.
Bug: 205338951
Test: soong test && m
Change-Id: I7ecab913e00c9b6a3ce870dacbe9773d2ddb7e93
We've also removed the last consumer of .mc files in aosp/1867048
(external/mdnsresponder/).
Bug: 203794880
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: I2883a04d04b099273261d76319261d0857aa0300
This converts cpp_std and gnu_extensions into a -std copt, if cpp_std is
specified or gnu_extensions is false if cpp_std is not specified.
I chose to go with this copts approach because the tradeoff is a much
simpler setting than adding a new attr(s) everywhere that uses features
to set the flag.
This approach limits the number of user-configurable knobs (since users
would then be able to set std in _both_ copts and the new attr). But it
does rely on the user copt overriding the toolchain's default gnu++17
version, which can mean a `-std` flag showing up twice in the action.
Fixes: b/202462232
Test: b build //system/libziparchive:libziparchive
Change-Id: I81dad029059461739b91f318d662e089edb46b84
Used as a supplement to C/C++ srcs to disable
clang-tidy for selected srcs, when a library
contains many files in srcs and only some of them
are too large to compile with clang-tidy.
Test: WITH_TIDY=1 TIDY_TIMEOUT=90 make tidy-soong
Bug: 198098397
Change-Id: Ib32eb0e46ddbc717999797717bfd8c57e182ee88
Refactor arch-handling code to return a "no-config" axis which allows
handling non-arch configed properties the same way as arch-configed
properties.
Test: build/bazel/ci/bp2build.sh
Change-Id: I485b35fd91c28501fe2055234dc9b278488bf4b5
This CL changes the logic in rust/builder.go so that some rustdoc flags
are only applied to external crates. This will allow us to since
warnings and deal with soft-failures in external crates while allowing
us to be more strict with our internal Rust code.
Bug: 195136952
Test: m rustdoc
Change-Id: Icdde304bbbb323cae9657e8f842f58ae79e811ce
Previously, isThirdParty check was over-selecting for third-party-ness,
the only non-third-party paths were those explicitly excluded from
typically third party directories, results in ~all code being considered
third party.
Updated test to ensure bionic is not considered third party, which fails
without this change.
Test: go soong tests
Change-Id: Id371aaad2ceef2b3163384fa84712397877cbe90
Following properties are added:
* vendor.header_libs
* platform.cflags
* platform.header_libs
* platform.exclude_shared_libs
These are used in the *-ndk libraries generated from the aidl_interface
modules, so that we can build the platform variants of the libraries
just like the *-ndk_platform libraries. Eventually, we will remove the
*-ndk_platform libraries.
Bug: 161456198
Test: m
Merged-In: I126e272cd29eb1e03662c54bfa8bd64e704adc74
Change-Id: I126e272cd29eb1e03662c54bfa8bd64e704adc74
(cherry picked from commit bb14481408)
Rename the ninja variables that have an extraneous Clang in the name,
since there are no longer any non-Clang variables.
Bug: 68947919
Test: no change to command lines used to build mmma bionic
Change-Id: I081d5e1d423a66d55faece6cb1d265cd5e504d5f
Remove cflags that are not handled by clang from the global defaults,
and remove calls to ClangFilterUnknownCflags.
Squash lists of clang-specific default flags into the main default
flags lists.
Rename Toolchain.Clang*flags to Toolchain.*flags.
Rename Go variables with Clang in the name that have no non-Clang
equivalent.
Remove unused ninja variables.
Bug: 68947919
Test: no change to build.ninja for aosp_cf_x86_64_phone-userdebug or aosp_crosshatch-userdebug
Change-Id: Id287945315d53e5eaef197adbbb4f1302f2e3680
This reverts commit cacb972dcd.
Relanding along with one more fix in prebuilts/ndk
Change-Id: I65cbc3c5d72bb47bd00e123c63911c9baa1e5f03
Test: m checkbuild
Add variant_prepend to Export_include_dirs, Export_system_include_dirs
and Generated_headers to match Local_include_dirs so that
architecture-specific headers are found before common headers.
Test: m checkbuild
Test: TestIncludeDirectoryOrdering
Change-Id: I2bf9d4373fd256e500c1f8d6c84cf593e8fdd170
Background:
When compiling cc_* modules, min_sdk_version determines the "version"
part of the clang triple: -target <arch>-linux-android<version>. The
version part is used to make sure that calls to the APIs that are added
after the version are guarded with a runtime check (i.e.
__builtin_available).
Previously, min_sdk_version was used as the version part only when the
cc_* module is unbundled (e.g. built for an APEX or built with SDK). In
other words, min_sdk_version has been ignored for the platform variants.
They were built with the version number 10000.
This was problematic for Mainline module tests. Since they are neither
part of an APEX nor built with SDK (because they need to have access to
some of the module-only APIs), they are built with the version number
10000. As a side effect, __builtin_available macro are expanded to 1 at
build time - because 10000 is higher than any API versions. When such a
test built in the latest platform source tree runs on a device running
an old platform, it tries to call an API that might not be available on
the platform and experience a crash, due to the lack of the runtime
check.
This change fixes the problem by using min_sdk_version as the "version"
part of the clang triple, regardless of the module's variant. Then
__builtin_available macro in the tests doesn't expand to 1, but to a
function call to the libclang_rt.builtin library which checks the system
property ro.build.version.sdk.
Bug: N/A
Test: run resolv_stress_test
Change-Id: I88f64c5a35f1b5276c3350e177b116932011a940
__ANDROID_VNDK__ is defined for the modules that are able to use the
VNDK libraries. As both product and vendor variants define
__ANDROID_VNDK__, we don't know if a module is built for vendor or
product on build time.
__ANDROID_VENDOR__ and __ANDROID_PRODUCT__ macros can be used to
specify the image-variant-dependent codes.
Bug: 180646847
Test: m nothing
Change-Id: Id6c3e1e3d47deaf3684c0c02964718658cf2fec5
Flags for external projects are specialisations of the common flags, and
need to follow the common flags, not precede them.
Bug: 181177782
Test: None
Change-Id: I19c8c2a3539573e9b2f2d9e3e1c898fa09570663
Previously, a cc library that included .aidl, .proto and/or .sysprop
files and exported headers generated from at least one of those types
would actually export generated headers from all of them.
While headers generated from .sysprop files are always exported those
generated from .aidl or .proto should only be exported when explicitly
requested.
This change treats them separately as expected. It has the potential
to break the build as it could reduce the set of headers exported and
so a dependent module that needed those would break. The fix in that
case is to simply add one (or both) of the following to the module
that previously exported those headers:
aidl: {
export_aidl_headers: true,
}
proto: {
export_proto_headers: true,
}
Bug: 180712399
Test: m droid
Change-Id: I488182e27dd423d261443612f98d5c112dd3ef8f
Previously, for cc_* modules, __ANDROID_API__ tracked the sdk_version
property. This however has caused a few number of problems:
1. It's confusing. __ANDROID_API__ has meant minSdkVersion. Therefore
the sdk_version property should mean minSdkVersion (since the macro
tracks the property). However, the introduction of the new
min_sdk_version property (which is currently for APEX) made this very
confusing. Also, this is not consistent with the java_* modules where
sdk_version means compileSdkVersion.
2. This is preventing go/android-future-symbols. The plan is to make the
APIs that are above the minSdkVersion available as weak symbols.
Previously those APIs had to be accessed via dlsym because they are
hidden behind the __ANDROID_API__ macro at build-time. To use make the
APIs visible at build-time, the module authors had to __ANDROID_API__
beyond their minSdkVersion. This is against the definition of
__ANDROID_API__.
To solve above problems, __ANDROID_API__ now correctly tracks
min_sdk_version. In addition, min_sdk_version now defaults to
sdk_version. Therefore, most of the modules that don't set
min_sdk_version aren't affected by this change.
Bug: 163288375
Test: m
Change-Id: I645e6bb1234c27ae0a69b7b87a59206cfd350744
The property can be used to pass additional flags to the AIDL compiler.
For example,
cc_library {
..
srcs: ["Foo.aidl"],
aidl: {
flags: [
"-Werror", // warnings as error
"-Weverything", // turn on all warnings
],
},
}
Bug: 168028537
Test: soong test
Change-Id: I8120eeae7cd7b1acdd34c554af996a29e760a368
With this patch, `vendor_available: true` will no longer creates
product variant. Instead, modules need to set `product_available:
true` if they have to be available to product vanriant.
If both properties are defined for VNDKs, they must have the same
values.
Bug: 150902910
Test: m nothing
Change-Id: I28fb6886e6114583227a31151136627c8516ac9c
__ANDROID_SDK_VERSION__ is ambiguous. Rename it
__ANDROID_APEX_MIN_SDK_VERSION__ so it's clear which SDK version it
refers to.
Note that this is still different from the minSdkVersion of the module
being compiled. This is the max of *all* the minSdkVersions of modules
that this module shares an APEX with.
Test: treehugger
Bug: None
Change-Id: Id9cbd80a6bc99db8227daef4e1db9c893e63ad1e
Allow rust_bindgen modules to define dependencies that only provide
headers and may not necessarily need to be linked in.
Bug: 161141999
Test: Soong tests pass.
Test: Example module has appropriate include flags when compiling.
Change-Id: Ic9ce8b1204008ad8dcb18766c914e48bb292d485
To make a module available to product variants, it must define
`product_available: true`. `vendor_available: true` will not create
product variants any more.
However, in this CL, we don't change the behavior of
`vendor_available` property. It still creates both variants. After we
update all Android.bp files that need to provide product variants
with `product_available: true`, we may upload the remaining patches.
Bug: 150902910
Test: lunch aosp_arm64-userdebug && m
Change-Id: I0fd5be7bbae2c45d5cab3c3c2ca49f53a9b6f975
rust_bindgen modules can't inherit properties in cc_defaults that would
be useful for generating bindings (such as cflags). This CL moves these
common properties out into a new struct in cc and adds that struct to
cc_default.
Additionally, Cppflags is added to rust_bindgen to make sure that these
get picked up as well from cc_defaults.
Bug: 163598610
Test: rust_bindgen module uses cflags in cc_defaults.
Test: New Soong test passes
Change-Id: I702442a355244dc01954083f98a2eebbcea12e47
Keeping the int constant around for now as FutureApiLevelInt because
it's still useful in places that haven't adopted ApiLevel yet for
testing if their non-ApiLevel API level is current or not.
Test: treehugger
Bug: http://b/154667674
Change-Id: I47a7012703f41fdeb56f91edf9c83afa93042deb
And remove dual meaning from arm_on_x86 target. It was set for x86
targets with arm support and for arm targets with x86 support - and that
2nd one was abused for native_bridge version of RenderScript.
It's much safer and cleaner to rely on __ANDROID_NATIVE_BRIDGE__ there
while leaving arm_on_x86 to mean "x86 binary built in the image with arm
support".
It's only used by bcc compiler which is in canadian-cross situation here:
it's pure x86-64 binary, but it needs to know about ALL supported
architectures on device because it needs to include appropriate codegen
module.
Bug: http://b/153609531
Test: cts-tradefed run cts --abi armeabi-v7a -m CtsRsCppTestCases
Test: cts-tradefed run cts --abi arm64-v8a -m CtsRsCppTestCases
Change-Id: I869212e0b82eeaa30361a4e183d5c862ab40ef12
An APEX module name, unlike the APEX package name, can contain
characters like '-', which are not allowed as C define strings.
Sanitize it properly.
Test: build GKI APEX
Change-Id: I8257d43c55862da8fab7f1e342c2d14369d1211e
To support module specific lexer flags, this follows the same strategy
as the yacc flags:
- add LexProperties to the BaseCompilerProperties
- propagate those flags to the generator generation (i.e. genLex)
- add a placeholder for custom flags
- replace the placeholder with the concatenated flags
This might not support escaping very well, but I figured that this is a
very edge case. Support for escaping etc. could be added later on.
Bug: 159682555
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I31a3b783bb05213fe1621191031952b41b318103
When a cc module sets UseApexNameMacro(mutated property), it is built
with __ANDROID_APEX_NAME__ for its apex variants.
For now the new prop is used by aidl_interface-generated modules only.
Note that we already have __ANDROID_APEX_<NAME>__ macro. The new macro
can be used when we need to pass the name as data while the old one is
useful when we want conditional compilation.
Bug: 165017590
Test: m com.android.aidltest
check build.ninja if -D__ANDROID_APEX_NAME__ is defined for apex
varaints
Change-Id: Ia81ba8f833d23254e58c9777daf184d7861f07a7
