* When WITH_TIDY=1, these targets allow quick check of C/C++
source code with clang-tidy, without building C/C++ binaries.
* For each module with tidy rules, add a module-tidy target, e.g.,
libart-tidy, libartd-tidy, bionic-benchmarks-tidy, libnativehelper-tidy, etc.
* Add a tidy-soong phony target that depends on all module-tidy targets.
* For each directory X/Y add a tidy-X-Y phony target that depends
on all *-tidy targets in X/Y and tidy-X-Y-Z for all X/Y/Z directories,
e.g., tidy-bionic, tidy-bionic-benchmarks, tidy-libnativehelper, etc.
* Only soong modules are collected for now.
Tidy rules in .mk files will be collected later.
* Some comment lines reformatted by gofmt.
Test: WITH_TIDY=1 make <some_module>-tidy tidy-<some_directory>
Test: WITH_TIDY=1 make tidy-soong
Bug: 199169329
Change-Id: I45aef3875f70288a8e070761e5f083dbbdfa6e94
* Do not run expensive clang-analyzer-* checks with googletest/*,
which should be checked upstream.
Test: make WITH_TIDY=1 CLANG_ANALYZER_CHECKS=1
Bug: 198098397
Change-Id: Ic801ffa802b42d4d55ae89553073c926f9eaa351
This code to support bp2build-specific modules is no longer necessary as
we do not create bp2build modules after https://r.android.com/1792714
Test: build/bazel/ci/bp2build.sh
Change-Id: I20d3c42f7e3516554cfb537fef05ba40d222dbeb
Both processes might consume a large amount of memory when analyzing
library ABIs. By chaining them via a pipe we keep the same
representation twice in memory. That can introduce a problematic peak
memory consumption. Hence, split them apart into separate rules that
depend on each other.
Bug: 191235788
Test: m out/soong/abi-dumps/ndk/28/x86_64/libc/abi.xml
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: Ia0264a5ede5b2c2a3c2e3fbe968c11d36acf33c2
The only case for this was Blueprint itself at build/blueprint, but with
that being a part of Soong, this special case is not necessary anymore.
Test: Presubmits.
Change-Id: Icc51cd80bd43f936a97018061cfbf76fc385e4c3
Replaces the BottomUpMutatorContext parameter with a new
SdkDependencyContext type that extends BottomUpMutatorContext. This is
to allow the sdk to pass additional information to the implementations
of that method to allow the behavior to be more finely tuned.
Bug: 195754365
Test: m nothing
Change-Id: I69c6d2c523934eb67d7a7e6c55c241e9b8a81773
We now default to lld for platform builds, removing all need for this
property. For more details, see "Effecient archive file handling" in
https://lld.llvm.org/NewLLD.html#key-concepts
Bug: 189475744
Test: Manual build succeeds
Change-Id: If1104d68b13de8c7afab35c1741a68f64394b448
Without this, any libraries with vendor: true set won't be included.
Bug: 197917632
Test: make haiku, run several fuzz targets on a device
Change-Id: Icab8d3f17d1f07f49940ee0ea52d9312a925affa
Previously, crt objects for APEX and vendor variants targetted API level
16 regardless of their context. For example, even if BOARD_VNDK_VERSION
is set to 29, or an APEX has `min_sdk_version: "29"`, the target API
level was from `min_sdk_version` property of the crt object which is set
to 16.
The meaning of min_sdk_version is quite different when it comes to crt
objects. It means the lowest API level that it CAN target for. It does
NOT mean the API level it SHOULD always target.
This has caused some other problems like TLS segment underalignment for
vendor libraries because the vendor libraries were all built with TLS
layout from API level 16.
This change fixes the problem by correctly implementing the different
semantic of min_sdk_version for crt objects.
Bug: N/A
Test: m nothing
Change-Id: I15328e0b6cbabbe151dd65c7469c6355e167b78a
Previously, crt modules didn't produce cc rules because they didn't have
any input src files set. This prevented us from having a test which
checks the cflags of the crt modules.
Fixing that by adding source file to the crt modules. crtbrand is also
added as an 'objs' dep, because otherwise partialLd rules won't be
generated.
Bug: N/A
Test: m nothing
Change-Id: I731227c20c662c876c40f0c41e1769a271e2c643
* changes:
Fix crtend for musl static binaries
Support static_executable: true for musl builds
Use SystemSharedLibs as StaticLibs for static executables
