A host target is considered as being cross-compiled when the target
can't run natively on the build machine. For example, linux_glibc/x86_64
is a non-cross target on a standard x86/Linux machine, but is a cross
host on Mac. Previously, whether cross or not was a static attribute of
an OsType. For example, Windows was always considered as cross host,
while linux_bionic was not. This becomes a problem when we support more
host targets like linux_bionic/arm64 which should be cross-host on
standard x86/Linux machines.
This change removes HostCross from the OsClass type and instead adds a
property HostCross to the Target type. When a target is being added, it
is initialized to true when the target can't run natively on the current
build machine.
Bug: 168086242
Test: m
Change-Id: Ic37c8db918873ddf324c86b12b5412952b0f2be2
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
Bug: http://b/119560349
Bug: http://b/168925229
To build with PGO instrumentation, the link step also needs
-fprofile-generate flag. Omitting this will result in a linker error.
This surfaces if module A depends on module B but PGO is used only for
module B.
Previous uses of PGO were avoiding or working around the issue but to
accommadate recent changes, this CL propagates the PGO linker flag to
module A.
Test: pgo-coral-config1 in release branch, TH
Change-Id: I12f6243152d4f5ea5526fbce03c25dba232ddab7
-fwhole_program_vtables depends on LTO being enabled. User manually
adding this through ldflag will break no LTO build configuration.
Test: TreeHugger
Change-Id: I557ec57831f01856a467f9567c3e7e25f8a6c566
We previously disabled inlining and unrolling completely during ThinLTO
in absense of PGO profile. For global ThinLTO, we want to better balance
binary size and performance.
We evaluated a number of combination of heuristics with global ThinLTO
configuration:
binary size change
no LTO baseline
no inline, no unroll -0.54%
no inline, unroll -0.50%
import-instr-limit=5, unroll +0.02%
import-instr-limit=10, unroll +0.13%
Loop unrolling does not contribute much to the binary size, therefore
it is re-enabled.
import-instr-limit=5 balances the binary size savings from ThinLTO and
size incrase due to additional optimisation.
Bug: 78485207
Bug: 169004486
Test: TreeHugger
Change-Id: I1c21153605e2ae42daa8857b06e27c081ee8ad85
Can happen if OUT_DIR is set on an absolute path.
Test: env RBE_remote_disabled=true OUT_DIR=/home_2/tmp/out m
Bug: 169048540
Fixes: 169048540
Change-Id: Ia6b91b13142d84e54d0dee8b4e04a91ad2cecc36
-fwhole-program-vtables cflag requires LTO to be enabled. Some projects
add this flag unconditionally, breaking builds that turn off LTO.
Make this an LTO property so that build system will handle adding the
flag when LTO is on.
Test: build
Bug: 169004486
Change-Id: Ifce12c09e1d6b8c2807314c3bb982b076efcaaa4
Handling of API levels within Soong is currently fairly difficult
since it isn't always clear based on context what kind of API level a
given string represents, how much canonicalizing and error checking
the code receiving the string are expected to do, or how those errors
should be treated.
The API level struct does not export its raw data, so as to keep its
"constructor" private to the android package, and to prevent misuse of
the `number` field, which is only an implementation detail for preview
API levels. API levels can be parsed with either
`android.ApiLevelFromUser`, which returns any errors to the caller, or
`android.ApiLevelOrPanic`, which is used in the case where the input
is trusted and any errors in parsing should panic. Even within the
`android` package, these APIs should be preferred over direct
construction.
For cases where there are context specific parsing requirements, such
as handling the "minimum" alias in the cc module,
`nativeApiLevelFromUser` and `nativeApiLevelOrPanic` should be used
instead.
Test: treehugger
Bug: http://b/154667674
Change-Id: Id52921fda32cb437fb1775ac2183299dedc0cf20
A per-context variable is used to store the list of modules that
contain stubs and their available versions. Stores the list of the
stubs versions on the implementation module, and then use the new
return values from AddVariationDependencies to expand dependencies
on implementation libraries to also depend on the stubs libraries.
Adds a new mutator pass to propagate list of stub versions to llndk
libraries.
Also creates an alias version variation called "latest" to allow
depending on the latest version without having to know what it is.
Test: all Soong tests
Test: no change to build.ninja, Android-${TARGET_PRODUCT}.mk, make_vars-${TARGET_PRODUCT}.mk or late-${TARGET_PRODUCT}.mk
Change-Id: If19659e2e5828c860fd4d679ef79a414b7ea2efc
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
It seems better to include this path directly rather than creating
symlinks in system/core that accomplish the same result.
Test: treehugger
Change-Id: I248a2f0450bbd5da132f67872ec018decba42725
Variants and paths are different there, and it is hard to test since
it's only in postsubmit in TH.
Test: m nothing
Bug: 168558897
Change-Id: I071540b3c7ff9a9fd4104dca75079e831b1b2529
The prebuilt-vs-source selection operates by setting SkipInstall on
either module. When the vendor-snapshot module visits all modules it
will visit both, and if it is a static library it will then add
duplicate install rules for both source and prebuilt unless it
looks at SkipInstall.
Test: `m nothing` in a tree with prebuilts/runtime present, that
has been updated with a snapshot after https://r.android.com/1398472,
which started to propagate vendor_available flags to prebuilts
snapshots.
Bug: 151303681
Change-Id: Ie425f0115e4180b7f4a8e682696697d55d666845
AddFarVariationDependencies was broken, which allowed apex to add
dependencies on tests by requesting an empty test_per_src variation
even though some test dependencies did not have a test_per_src
variation. Add an alias from the pre-test_per_src variation
variant to the empty test_per_src variation, and drop the
test_per_src variation when requesting the depencency.
Test: TestApexWithTests
Change-Id: I2ed7bdd761027956141e25d4d81f9074afe628b6
