platform_build_soong/sdk/cc_sdk_test.go

2714 lines
70 KiB
Go
Raw Normal View History

// Copyright (C) 2019 The Android Open Source Project
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package sdk
import (
"testing"
"android/soong/android"
"android/soong/cc"
)
var ccTestFs = android.MockFS{
"Test.cpp": nil,
"myinclude/Test.h": nil,
"myinclude-android/AndroidTest.h": nil,
"myinclude-host/HostTest.h": nil,
"arm64/include/Arm64Test.h": nil,
"libfoo.so": nil,
"aidl/foo/bar/Test.aidl": nil,
"some/where/stubslib.map.txt": nil,
}
func testSdkWithCc(t *testing.T, bp string) *android.TestResult {
t.Helper()
return testSdkWithFs(t, bp, ccTestFs)
}
// Contains tests for SDK members provided by the cc package.
func TestSingleDeviceOsAssumption(t *testing.T) {
// Mock a module with DeviceSupported() == true.
s := &sdk{}
android.InitAndroidArchModule(s, android.DeviceSupported, android.MultilibCommon)
osTypes := s.getPossibleOsTypes()
if len(osTypes) != 1 {
// The snapshot generation assumes there is a single device OS. If more are
// added it might need to disable them by default, like it does for host
// OS'es.
t.Errorf("expected a single device OS, got %v", osTypes)
}
}
func TestSdkIsCompileMultilibBoth(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["sdkmember"],
}
cc_library_shared {
name: "sdkmember",
srcs: ["Test.cpp"],
stl: "none",
}
`)
armOutput := result.Module("sdkmember", "android_arm_armv7-a-neon_shared").(*cc.Module).OutputFile()
arm64Output := result.Module("sdkmember", "android_arm64_armv8-a_shared").(*cc.Module).OutputFile()
var inputs []string
buildParams := result.Module("mysdk", android.CommonOS.Name).BuildParamsForTests()
for _, bp := range buildParams {
if bp.Input != nil {
inputs = append(inputs, bp.Input.String())
}
}
// ensure that both 32/64 outputs are inputs of the sdk snapshot
ensureListContains(t, inputs, armOutput.String())
ensureListContains(t, inputs, arm64Output.String())
}
func TestSdkCompileMultilibOverride(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
host_supported: true,
native_shared_libs: ["sdkmember"],
compile_multilib: "64",
}
cc_library_shared {
name: "sdkmember",
host_supported: true,
srcs: ["Test.cpp"],
stl: "none",
compile_multilib: "64",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "sdkmember",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/sdkmember.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/sdkmember.so"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_sdkmember@current",
sdk_member_name: "sdkmember",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/sdkmember.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/sdkmember.so"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
host_supported: true,
native_shared_libs: ["mysdk_sdkmember@current"],
compile_multilib: "64",
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/sdkmember/android_arm64_armv8-a_shared/sdkmember.so -> android/arm64/lib/sdkmember.so
.intermediates/sdkmember/linux_glibc_x86_64_shared/sdkmember.so -> linux_glibc/x86_64/lib/sdkmember.so
`))
}
func TestBasicSdkWithCc(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["sdkmember"],
}
cc_library_shared {
name: "sdkmember",
system_shared_libs: [],
stl: "none",
apex_available: ["mysdkapex"],
}
sdk_snapshot {
name: "mysdk@1",
native_shared_libs: ["sdkmember_mysdk_1"],
}
sdk_snapshot {
name: "mysdk@2",
native_shared_libs: ["sdkmember_mysdk_2"],
}
cc_prebuilt_library_shared {
name: "sdkmember",
srcs: ["libfoo.so"],
prefer: false,
system_shared_libs: [],
stl: "none",
}
cc_prebuilt_library_shared {
name: "sdkmember_mysdk_1",
sdk_member_name: "sdkmember",
srcs: ["libfoo.so"],
system_shared_libs: [],
stl: "none",
// TODO: remove //apex_available:platform
apex_available: [
"//apex_available:platform",
"myapex",
],
}
cc_prebuilt_library_shared {
name: "sdkmember_mysdk_2",
sdk_member_name: "sdkmember",
srcs: ["libfoo.so"],
system_shared_libs: [],
stl: "none",
// TODO: remove //apex_available:platform
apex_available: [
"//apex_available:platform",
"myapex2",
],
}
cc_library_shared {
name: "mycpplib",
srcs: ["Test.cpp"],
shared_libs: ["sdkmember"],
system_shared_libs: [],
stl: "none",
apex_available: [
"myapex",
"myapex2",
],
}
apex {
name: "myapex",
native_shared_libs: ["mycpplib"],
uses_sdks: ["mysdk@1"],
key: "myapex.key",
certificate: ":myapex.cert",
updatable: false,
}
apex {
name: "myapex2",
native_shared_libs: ["mycpplib"],
uses_sdks: ["mysdk@2"],
key: "myapex.key",
certificate: ":myapex.cert",
updatable: false,
}
apex {
name: "mysdkapex",
native_shared_libs: ["sdkmember"],
key: "myapex.key",
certificate: ":myapex.cert",
updatable: false,
}
`)
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-12 03:17:01 +08:00
sdkMemberV1 := result.ModuleForTests("sdkmember_mysdk_1", "android_arm64_armv8-a_shared_apex10000_mysdk_1").Rule("toc").Output
sdkMemberV2 := result.ModuleForTests("sdkmember_mysdk_2", "android_arm64_armv8-a_shared_apex10000_mysdk_2").Rule("toc").Output
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-12 03:17:01 +08:00
cpplibForMyApex := result.ModuleForTests("mycpplib", "android_arm64_armv8-a_shared_apex10000_mysdk_1")
cpplibForMyApex2 := result.ModuleForTests("mycpplib", "android_arm64_armv8-a_shared_apex10000_mysdk_2")
// Depending on the uses_sdks value, different libs are linked
ensureListContains(t, pathsToStrings(cpplibForMyApex.Rule("ld").Implicits), sdkMemberV1.String())
ensureListContains(t, pathsToStrings(cpplibForMyApex2.Rule("ld").Implicits), sdkMemberV2.String())
}
// Make sure the sdk can use host specific cc libraries static/shared and both.
func TestHostSdkWithCc(t *testing.T) {
testSdkWithCc(t, `
sdk {
name: "mysdk",
device_supported: false,
host_supported: true,
native_shared_libs: ["sdkshared"],
native_static_libs: ["sdkstatic"],
}
cc_library_host_shared {
name: "sdkshared",
stl: "none",
}
cc_library_host_static {
name: "sdkstatic",
stl: "none",
}
`)
}
// Make sure the sdk can use cc libraries static/shared and both.
func TestSdkWithCc(t *testing.T) {
testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["sdkshared", "sdkboth1"],
native_static_libs: ["sdkstatic", "sdkboth2"],
}
cc_library_shared {
name: "sdkshared",
stl: "none",
}
cc_library_static {
name: "sdkstatic",
stl: "none",
}
cc_library {
name: "sdkboth1",
stl: "none",
}
cc_library {
name: "sdkboth2",
stl: "none",
}
`)
}
func TestSnapshotWithObject(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_objects: ["crtobj"],
}
cc_object {
name: "crtobj",
stl: "none",
sanitize: {
never: true,
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_object {
name: "crtobj",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
sanitize: {
never: true,
},
arch: {
arm64: {
srcs: ["arm64/lib/crtobj.o"],
},
arm: {
srcs: ["arm/lib/crtobj.o"],
},
},
}
`),
// Make sure that the generated sdk_snapshot uses the native_objects property.
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_object {
name: "mysdk_crtobj@current",
sdk_member_name: "crtobj",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
sanitize: {
never: true,
},
arch: {
arm64: {
srcs: ["arm64/lib/crtobj.o"],
},
arm: {
srcs: ["arm/lib/crtobj.o"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
native_objects: ["mysdk_crtobj@current"],
}
`),
checkAllCopyRules(`
.intermediates/crtobj/android_arm64_armv8-a/crtobj.o -> arm64/lib/crtobj.o
.intermediates/crtobj/android_arm_armv7-a-neon/crtobj.o -> arm/lib/crtobj.o
`),
)
}
func TestSnapshotWithCcDuplicateHeaders(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["mynativelib1", "mynativelib2"],
}
cc_library_shared {
name: "mynativelib1",
srcs: [
"Test.cpp",
],
export_include_dirs: ["myinclude"],
stl: "none",
}
cc_library_shared {
name: "mynativelib2",
srcs: [
"Test.cpp",
],
export_include_dirs: ["myinclude"],
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib1/android_arm64_armv8-a_shared/mynativelib1.so -> arm64/lib/mynativelib1.so
.intermediates/mynativelib1/android_arm_armv7-a-neon_shared/mynativelib1.so -> arm/lib/mynativelib1.so
.intermediates/mynativelib2/android_arm64_armv8-a_shared/mynativelib2.so -> arm64/lib/mynativelib2.so
.intermediates/mynativelib2/android_arm_armv7-a-neon_shared/mynativelib2.so -> arm/lib/mynativelib2.so
`),
)
}
func TestSnapshotWithCcExportGeneratedHeaders(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["mynativelib"],
}
cc_library_shared {
name: "mynativelib",
srcs: [
"Test.cpp",
],
generated_headers: [
"generated_foo",
],
export_generated_headers: [
"generated_foo",
],
export_include_dirs: ["myinclude"],
stl: "none",
}
genrule {
name: "generated_foo",
cmd: "generate-foo",
out: [
"generated_foo/protos/foo/bar.h",
],
export_include_dirs: [
".",
"protos",
],
}
`)
// TODO(b/183322862): Remove this and fix the issue.
errorHandler := android.FixtureExpectsAtLeastOneErrorMatchingPattern(`module source path "snapshot/include_gen/generated_foo/gen/protos" does not exist`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
export_include_dirs: [
"include/myinclude",
"include_gen/generated_foo/gen",
"include_gen/generated_foo/gen/protos",
],
arch: {
arm64: {
srcs: ["arm64/lib/mynativelib.so"],
},
arm: {
srcs: ["arm/lib/mynativelib.so"],
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/generated_foo/gen/generated_foo/protos/foo/bar.h -> include_gen/generated_foo/gen/generated_foo/protos/foo/bar.h
.intermediates/mynativelib/android_arm64_armv8-a_shared/mynativelib.so -> arm64/lib/mynativelib.so
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so
`),
snapshotTestErrorHandler(checkSnapshotWithoutSource, errorHandler),
snapshotTestErrorHandler(checkSnapshotWithSourcePreferred, errorHandler),
snapshotTestErrorHandler(checkSnapshotPreferredWithSource, errorHandler),
)
}
// Verify that when the shared library has some common and some arch specific
// properties that the generated snapshot is optimized properly. Substruct
// handling is tested with the sanitize clauses (but note there's a lot of
// built-in logic in sanitize.go that can affect those flags).
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
func TestSnapshotWithCcSharedLibraryCommonProperties(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["mynativelib"],
}
cc_library_shared {
name: "mynativelib",
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
export_include_dirs: ["myinclude"],
sanitize: {
fuzzer: false,
integer_overflow: true,
diag: { undefined: false },
},
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
arch: {
arm64: {
export_system_include_dirs: ["arm64/include"],
sanitize: {
integer_overflow: false,
},
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
},
},
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
sanitize: {
fuzzer: false,
diag: {
undefined: false,
},
},
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
arch: {
arm64: {
srcs: ["arm64/lib/mynativelib.so"],
export_system_include_dirs: ["arm64/include/arm64/include"],
sanitize: {
integer_overflow: false,
},
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
},
arm: {
srcs: ["arm/lib/mynativelib.so"],
sanitize: {
integer_overflow: true,
},
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_shared/mynativelib.so -> arm64/lib/mynativelib.so
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
arm64/include/Arm64Test.h -> arm64/include/arm64/include/Arm64Test.h
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so`),
Generalize common property extraction Previously, code that attempted to optimize the generated .bp rules treated the properties structure as a single entity. So, a single arch specific value would cause all properties to be treated as arch specific. Also, that code was specific to one structure type. This generalizes the optimization to work with any properties structure which will be helpful for other multi-variant module types. It also treats each property separately. The hasArchSpecificFlags field has been removed from nativeLibInfo and a commonProperties field has been added instead into which the common values will be found. File path creation that conditionally prefixed a path with archType has been replaced with general code that relies on archType being "" for common properties and filepath.Join(..) ignoring empty string components. The common and arch variant properties are always processed. The first within the context of the .bp module's property set and the latter within an arch specific property set. There are always some properties that are arch specific, e.g. outputFile, so there is no need to worry about an empty arch property set being created. The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties as it may not be arch specific. The printExportedDirCopyCommandsForNativeLibs variable was renamed to addExportedDirCopyCommandsForNativeLibs as it no longer does any printing. Bug: 142918168 Test: m checkbuild Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
2019-12-12 04:00:57 +08:00
)
}
func TestSnapshotWithCcBinary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "mymodule_exports",
native_binaries: ["mynativebinary"],
}
cc_binary {
name: "mynativebinary",
srcs: [
"Test.cpp",
],
compile_multilib: "both",
}
`)
CheckSnapshot(t, result, "mymodule_exports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "mynativebinary",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
arch: {
arm64: {
srcs: ["arm64/bin/mynativebinary"],
},
arm: {
srcs: ["arm/bin/mynativebinary"],
},
},
}
`),
// Make sure that the generated sdk_snapshot uses the native_binaries property.
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "mymodule_exports_mynativebinary@current",
sdk_member_name: "mynativebinary",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
installable: false,
compile_multilib: "both",
arch: {
arm64: {
srcs: ["arm64/bin/mynativebinary"],
},
arm: {
srcs: ["arm/bin/mynativebinary"],
},
},
}
module_exports_snapshot {
name: "mymodule_exports@current",
visibility: ["//visibility:public"],
native_binaries: ["mymodule_exports_mynativebinary@current"],
}
`),
checkAllCopyRules(`
.intermediates/mynativebinary/android_arm64_armv8-a/mynativebinary -> arm64/bin/mynativebinary
.intermediates/mynativebinary/android_arm_armv7-a-neon/mynativebinary -> arm/bin/mynativebinary
`),
)
}
func TestMultipleHostOsTypesSnapshotWithCcBinary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "myexports",
device_supported: false,
host_supported: true,
native_binaries: ["mynativebinary"],
target: {
windows: {
enabled: true,
},
},
}
cc_binary {
name: "mynativebinary",
device_supported: false,
host_supported: true,
srcs: [
"Test.cpp",
],
compile_multilib: "both",
stl: "none",
target: {
windows: {
enabled: true,
},
},
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "mynativebinary",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
target: {
host: {
enabled: false,
},
linux_glibc: {
compile_multilib: "both",
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/bin/mynativebinary"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/bin/mynativebinary"],
},
windows: {
compile_multilib: "64",
},
windows_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["windows/x86_64/bin/mynativebinary.exe"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "myexports_mynativebinary@current",
sdk_member_name: "mynativebinary",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
target: {
host: {
enabled: false,
},
linux_glibc: {
compile_multilib: "both",
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/bin/mynativebinary"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/bin/mynativebinary"],
},
windows: {
compile_multilib: "64",
},
windows_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["windows/x86_64/bin/mynativebinary.exe"],
},
},
}
module_exports_snapshot {
name: "myexports@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_binaries: ["myexports_mynativebinary@current"],
target: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
windows: {
compile_multilib: "64",
},
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86: {
enabled: true,
},
windows_x86_64: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/mynativebinary/linux_glibc_x86_64/mynativebinary -> linux_glibc/x86_64/bin/mynativebinary
.intermediates/mynativebinary/linux_glibc_x86/mynativebinary -> linux_glibc/x86/bin/mynativebinary
.intermediates/mynativebinary/windows_x86_64/mynativebinary.exe -> windows/x86_64/bin/mynativebinary.exe
`),
)
}
func TestSnapshotWithSingleHostOsType(t *testing.T) {
result := android.GroupFixturePreparers(
prepareForSdkTest,
ccTestFs.AddToFixture(),
cc.PrepareForTestOnLinuxBionic,
android.FixtureModifyConfig(func(config android.Config) {
config.Targets[android.LinuxBionic] = []android.Target{
{android.LinuxBionic, android.Arch{ArchType: android.X86_64}, android.NativeBridgeDisabled, "", "", false},
}
}),
).RunTestWithBp(t, `
cc_defaults {
name: "mydefaults",
device_supported: false,
host_supported: true,
compile_multilib: "64",
target: {
host: {
enabled: false,
},
linux_bionic: {
enabled: true,
},
},
}
module_exports {
name: "myexports",
defaults: ["mydefaults"],
native_shared_libs: ["mynativelib"],
native_binaries: ["mynativebinary"],
compile_multilib: "64", // The built-in default in sdk.go overrides mydefaults.
}
cc_library {
name: "mynativelib",
defaults: ["mydefaults"],
srcs: [
"Test.cpp",
],
stl: "none",
}
cc_binary {
name: "mynativebinary",
defaults: ["mydefaults"],
srcs: [
"Test.cpp",
],
stl: "none",
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "mynativebinary",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
linux_bionic_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/bin/mynativebinary"],
},
},
}
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
linux_bionic_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.so"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "myexports_mynativebinary@current",
sdk_member_name: "mynativebinary",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
linux_bionic_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/bin/mynativebinary"],
},
},
}
cc_prebuilt_library_shared {
name: "myexports_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "64",
target: {
host: {
enabled: false,
},
linux_bionic_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.so"],
},
},
}
module_exports_snapshot {
name: "myexports@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_binaries: ["myexports_mynativebinary@current"],
native_shared_libs: ["myexports_mynativelib@current"],
compile_multilib: "64",
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_bionic_x86_64: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/mynativebinary/linux_bionic_x86_64/mynativebinary -> x86_64/bin/mynativebinary
.intermediates/mynativelib/linux_bionic_x86_64_shared/mynativelib.so -> x86_64/lib/mynativelib.so
`),
)
}
// Test that we support the necessary flags for the linker binary, which is
// special in several ways.
func TestSnapshotWithCcStaticNocrtBinary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "mymodule_exports",
host_supported: true,
device_supported: false,
native_binaries: ["linker"],
}
cc_binary {
name: "linker",
host_supported: true,
static_executable: true,
nocrt: true,
stl: "none",
srcs: [
"Test.cpp",
],
compile_multilib: "both",
}
`)
CheckSnapshot(t, result, "mymodule_exports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "linker",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "both",
static_executable: true,
nocrt: true,
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/bin/linker"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/bin/linker"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_binary {
name: "mymodule_exports_linker@current",
sdk_member_name: "linker",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "both",
static_executable: true,
nocrt: true,
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/bin/linker"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/bin/linker"],
},
},
}
module_exports_snapshot {
name: "mymodule_exports@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_binaries: ["mymodule_exports_linker@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/linker/linux_glibc_x86_64/linker -> x86_64/bin/linker
.intermediates/linker/linux_glibc_x86/linker -> x86/bin/linker
`),
)
}
func TestSnapshotWithCcSharedLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["mynativelib"],
}
cc_library_shared {
name: "mynativelib",
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
apex_available: ["apex1", "apex2"],
export_include_dirs: ["myinclude"],
aidl: {
export_aidl_headers: true,
},
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: [
"apex1",
"apex2",
],
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
arch: {
arm64: {
srcs: ["arm64/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["arm64/include_gen/mynativelib/android_arm64_armv8-a_shared/gen/aidl"],
},
arm: {
srcs: ["arm/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["arm/include_gen/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl"],
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_shared/mynativelib.so -> arm64/lib/mynativelib.so
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/Test.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/BnTest.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/BpTest.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_shared/gen/aidl/aidl/foo/bar/BpTest.h
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/Test.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/BnTest.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/BpTest.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_shared/gen/aidl/aidl/foo/bar/BpTest.h
`),
)
}
func TestSnapshotWithCcSharedLibrarySharedLibs(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: [
"mynativelib",
"myothernativelib",
"mysystemnativelib",
],
}
cc_library {
name: "mysystemnativelib",
srcs: [
"Test.cpp",
],
stl: "none",
}
cc_library_shared {
name: "myothernativelib",
srcs: [
"Test.cpp",
],
system_shared_libs: [
// A reference to a library that is not an sdk member. Uses libm as that
// is in the default set of modules available to this test and so is available
// both here and also when the generated Android.bp file is tested in
// CheckSnapshot(). This ensures that the system_shared_libs property correctly
// handles references to modules that are not sdk members.
"libm",
],
stl: "none",
}
cc_library {
name: "mynativelib",
srcs: [
"Test.cpp",
],
shared_libs: [
// A reference to another sdk member.
"myothernativelib",
],
target: {
android: {
shared: {
shared_libs: [
// A reference to a library that is not an sdk member. The libc library
// is used here to check that the shared_libs property is handled correctly
// in a similar way to how libm is used to check system_shared_libs above.
"libc",
],
},
},
},
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
shared_libs: [
"myothernativelib",
"libc",
],
arch: {
arm64: {
srcs: ["arm64/lib/mynativelib.so"],
},
arm: {
srcs: ["arm/lib/mynativelib.so"],
},
},
}
cc_prebuilt_library_shared {
name: "myothernativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
system_shared_libs: ["libm"],
arch: {
arm64: {
srcs: ["arm64/lib/myothernativelib.so"],
},
arm: {
srcs: ["arm/lib/myothernativelib.so"],
},
},
}
cc_prebuilt_library_shared {
name: "mysystemnativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
arch: {
arm64: {
srcs: ["arm64/lib/mysystemnativelib.so"],
},
arm: {
srcs: ["arm/lib/mysystemnativelib.so"],
},
},
}
`),
checkAllCopyRules(`
.intermediates/mynativelib/android_arm64_armv8-a_shared/mynativelib.so -> arm64/lib/mynativelib.so
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so
.intermediates/myothernativelib/android_arm64_armv8-a_shared/myothernativelib.so -> arm64/lib/myothernativelib.so
.intermediates/myothernativelib/android_arm_armv7-a-neon_shared/myothernativelib.so -> arm/lib/myothernativelib.so
.intermediates/mysystemnativelib/android_arm64_armv8-a_shared/mysystemnativelib.so -> arm64/lib/mysystemnativelib.so
.intermediates/mysystemnativelib/android_arm_armv7-a-neon_shared/mysystemnativelib.so -> arm/lib/mysystemnativelib.so
`),
)
}
func TestHostSnapshotWithCcSharedLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
device_supported: false,
host_supported: true,
native_shared_libs: ["mynativelib"],
}
cc_library_shared {
name: "mynativelib",
device_supported: false,
host_supported: true,
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
export_include_dirs: ["myinclude"],
aidl: {
export_aidl_headers: true,
},
stl: "none",
sdk_version: "minimum",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
sdk_version: "minimum",
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86_64/include_gen/mynativelib/linux_glibc_x86_64_shared/gen/aidl"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86/include_gen/mynativelib/linux_glibc_x86_shared/gen/aidl"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
sdk_version: "minimum",
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86_64/include_gen/mynativelib/linux_glibc_x86_64_shared/gen/aidl"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/lib/mynativelib.so"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86/include_gen/mynativelib/linux_glibc_x86_shared/gen/aidl"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_shared_libs: ["mysdk_mynativelib@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_shared/mynativelib.so -> x86_64/lib/mynativelib.so
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/Test.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/BnTest.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/BpTest.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_shared/gen/aidl/aidl/foo/bar/BpTest.h
.intermediates/mynativelib/linux_glibc_x86_shared/mynativelib.so -> x86/lib/mynativelib.so
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/Test.h -> x86/include_gen/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/BnTest.h -> x86/include_gen/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/BpTest.h -> x86/include_gen/mynativelib/linux_glibc_x86_shared/gen/aidl/aidl/foo/bar/BpTest.h
`),
)
}
func TestMultipleHostOsTypesSnapshotWithCcSharedLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
device_supported: false,
host_supported: true,
native_shared_libs: ["mynativelib"],
target: {
windows: {
enabled: true,
},
},
}
cc_library_shared {
name: "mynativelib",
device_supported: false,
host_supported: true,
srcs: [
"Test.cpp",
],
stl: "none",
target: {
windows: {
enabled: true,
},
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
target: {
host: {
enabled: false,
},
linux_glibc: {
compile_multilib: "both",
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/mynativelib.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/mynativelib.so"],
},
windows: {
compile_multilib: "64",
},
windows_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["windows/x86_64/lib/mynativelib.dll"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
target: {
host: {
enabled: false,
},
linux_glibc: {
compile_multilib: "both",
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/mynativelib.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/mynativelib.so"],
},
windows: {
compile_multilib: "64",
},
windows_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["windows/x86_64/lib/mynativelib.dll"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_shared_libs: ["mysdk_mynativelib@current"],
target: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
windows: {
compile_multilib: "64",
},
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86: {
enabled: true,
},
windows_x86_64: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/mynativelib/linux_glibc_x86_64_shared/mynativelib.so -> linux_glibc/x86_64/lib/mynativelib.so
.intermediates/mynativelib/linux_glibc_x86_shared/mynativelib.so -> linux_glibc/x86/lib/mynativelib.so
.intermediates/mynativelib/windows_x86_64_shared/mynativelib.dll -> windows/x86_64/lib/mynativelib.dll
`),
)
}
func TestSnapshotWithCcStaticLibrary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "myexports",
native_static_libs: ["mynativelib"],
}
cc_library_static {
name: "mynativelib",
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
export_include_dirs: ["myinclude"],
aidl: {
export_aidl_headers: true,
},
stl: "none",
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_static {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
arch: {
arm64: {
srcs: ["arm64/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["arm64/include_gen/mynativelib/android_arm64_armv8-a_static/gen/aidl"],
},
arm: {
srcs: ["arm/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["arm/include_gen/mynativelib/android_arm_armv7-a-neon_static/gen/aidl"],
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_static/mynativelib.a -> arm64/lib/mynativelib.a
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/Test.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/BnTest.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/BpTest.h -> arm64/include_gen/mynativelib/android_arm64_armv8-a_static/gen/aidl/aidl/foo/bar/BpTest.h
.intermediates/mynativelib/android_arm_armv7-a-neon_static/mynativelib.a -> arm/lib/mynativelib.a
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/Test.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/BnTest.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/BpTest.h -> arm/include_gen/mynativelib/android_arm_armv7-a-neon_static/gen/aidl/aidl/foo/bar/BpTest.h
`),
)
}
func TestHostSnapshotWithCcStaticLibrary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "myexports",
device_supported: false,
host_supported: true,
native_static_libs: ["mynativelib"],
}
cc_library_static {
name: "mynativelib",
device_supported: false,
host_supported: true,
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
export_include_dirs: ["myinclude"],
aidl: {
export_aidl_headers: true,
},
stl: "none",
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_static {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86_64/include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86/include_gen/mynativelib/linux_glibc_x86_static/gen/aidl"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_static {
name: "myexports_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86_64/include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86/lib/mynativelib.a"],
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
export_include_dirs: ["x86/include_gen/mynativelib/linux_glibc_x86_static/gen/aidl"],
},
},
}
module_exports_snapshot {
name: "myexports@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_static_libs: ["myexports_mynativelib@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_static/mynativelib.a -> x86_64/lib/mynativelib.a
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/Test.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BnTest.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BpTest.h -> x86_64/include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BpTest.h
.intermediates/mynativelib/linux_glibc_x86_static/mynativelib.a -> x86/lib/mynativelib.a
Fix the snapshot handling of generated headers Previously, the snapshot handling code did not preserve the directory structure of generated include directories and instead just copied the headers into the same module specific directory and added that single directory to the export_include_dirs (or similar) property. That had a couple of issues: * The include directory was repeated in the ..._include_dirs property. * It did not work when the include directories overlapped. In the latter case it had a couple of issues: * Code which compiled fine against the source would not compile against the prebuilt. * Header files were duplicated in the output. e.g. assume the following generated header file structure: foo/ foo.h bar/ bar.h baz/ baz.h When the sdk snapshot was passed include directories of "foo", "bar" and headers of "foo/foo.h", "bar/bar.h", "bar/baz/baz.h" it would generate a snapshot with the structure: include_gen/ foo.h bar.h baz/ baz.h And: export_include_dirs: ["include_gen", "include_gen"] However, when the include directories overlapped and include directories of "foo", "bar" and "bar/baz" were passed in the directory structure would be the same and the export_include_dirs would contain 3 usages of "include_gen". That meant that source code which used the following would build against the source (because it would find "baz.h" in the "bar/baz" include directory) but would fail when built against the prebuilts because the "include_gen" directory did not contain "baz.h": #include "baz.h" This change preserves the input directory structure for generated files in a similar way to how it does it for source files. So, the snapshot structure looks something like this: include_gen/ foo/ foo.h bar/ bar.h baz/ baz.h And: export_include_dirs: [ "include_gen/foo", "include_gen/bar", "include_gen/bar/baz", ], Bug: 180427921 Test: m nothing Change-Id: Id69eef8cf5eecd033841d3b7cd0c044a697ce404
2021-02-22 19:35:24 +08:00
.intermediates/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/Test.h -> x86/include_gen/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/BnTest.h -> x86/include_gen/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/BpTest.h -> x86/include_gen/mynativelib/linux_glibc_x86_static/gen/aidl/aidl/foo/bar/BpTest.h
`),
)
}
func TestSnapshotWithCcLibrary(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "myexports",
native_libs: ["mynativelib"],
}
cc_library {
name: "mynativelib",
srcs: [
"Test.cpp",
],
export_include_dirs: ["myinclude"],
stl: "none",
recovery_available: true,
vendor_available: true,
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
recovery_available: true,
vendor_available: true,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
arch: {
arm64: {
static: {
srcs: ["arm64/lib/mynativelib.a"],
},
shared: {
srcs: ["arm64/lib/mynativelib.so"],
},
},
arm: {
static: {
srcs: ["arm/lib/mynativelib.a"],
},
shared: {
srcs: ["arm/lib/mynativelib.so"],
},
},
},
}
`),
// Make sure that the generated sdk_snapshot uses the native_libs property.
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library {
name: "myexports_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
installable: false,
recovery_available: true,
vendor_available: true,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
arch: {
arm64: {
static: {
srcs: ["arm64/lib/mynativelib.a"],
},
shared: {
srcs: ["arm64/lib/mynativelib.so"],
},
},
arm: {
static: {
srcs: ["arm/lib/mynativelib.a"],
},
shared: {
srcs: ["arm/lib/mynativelib.so"],
},
},
},
}
module_exports_snapshot {
name: "myexports@current",
visibility: ["//visibility:public"],
native_libs: ["myexports_mynativelib@current"],
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/android_arm64_armv8-a_static/mynativelib.a -> arm64/lib/mynativelib.a
.intermediates/mynativelib/android_arm64_armv8-a_shared/mynativelib.so -> arm64/lib/mynativelib.so
.intermediates/mynativelib/android_arm_armv7-a-neon_static/mynativelib.a -> arm/lib/mynativelib.a
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so
`),
// TODO(b/183315522): Remove this and fix the issue.
snapshotTestErrorHandler(checkSnapshotPreferredWithSource, android.FixtureExpectsAtLeastOneErrorMatchingPattern(`\Qunrecognized property "arch.arm.shared.export_include_dirs"\E`)),
)
}
func TestHostSnapshotWithMultiLib64(t *testing.T) {
result := testSdkWithCc(t, `
module_exports {
name: "myexports",
device_supported: false,
host_supported: true,
target: {
host: {
compile_multilib: "64",
},
},
native_static_libs: ["mynativelib"],
}
cc_library_static {
name: "mynativelib",
device_supported: false,
host_supported: true,
srcs: [
"Test.cpp",
"aidl/foo/bar/Test.aidl",
],
export_include_dirs: ["myinclude"],
aidl: {
export_aidl_headers: true,
},
stl: "none",
}
`)
CheckSnapshot(t, result, "myexports", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_static {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "64",
export_include_dirs: [
"include/myinclude",
"include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl",
],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.a"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_static {
name: "myexports_mynativelib@current",
sdk_member_name: "mynativelib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
installable: false,
stl: "none",
compile_multilib: "64",
export_include_dirs: [
"include/myinclude",
"include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl",
],
target: {
host: {
enabled: false,
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["x86_64/lib/mynativelib.a"],
},
},
}
module_exports_snapshot {
name: "myexports@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_static_libs: ["myexports_mynativelib@current"],
compile_multilib: "64",
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/Test.h -> include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/Test.h
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BnTest.h -> include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BnTest.h
.intermediates/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BpTest.h -> include_gen/mynativelib/linux_glibc_x86_64_static/gen/aidl/aidl/foo/bar/BpTest.h
.intermediates/mynativelib/linux_glibc_x86_64_static/mynativelib.a -> x86_64/lib/mynativelib.a
`),
)
}
func TestSnapshotWithCcHeadersLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_header_libs: ["mynativeheaders"],
}
cc_library_headers {
name: "mynativeheaders",
export_include_dirs: ["myinclude"],
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_headers {
name: "mynativeheaders",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
`),
)
}
func TestHostSnapshotWithCcHeadersLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
device_supported: false,
host_supported: true,
native_header_libs: ["mynativeheaders"],
}
cc_library_headers {
name: "mynativeheaders",
device_supported: false,
host_supported: true,
export_include_dirs: ["myinclude"],
stl: "none",
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_headers {
name: "mynativeheaders",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_headers {
name: "mysdk_mynativeheaders@current",
sdk_member_name: "mynativeheaders",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
device_supported: false,
host_supported: true,
stl: "none",
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
device_supported: false,
host_supported: true,
native_header_libs: ["mysdk_mynativeheaders@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
`),
)
}
func TestDeviceAndHostSnapshotWithCcHeadersLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
host_supported: true,
native_header_libs: ["mynativeheaders"],
}
cc_library_headers {
name: "mynativeheaders",
host_supported: true,
stl: "none",
export_system_include_dirs: ["myinclude"],
target: {
android: {
export_include_dirs: ["myinclude-android"],
},
host: {
export_include_dirs: ["myinclude-host"],
},
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_headers {
name: "mynativeheaders",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
stl: "none",
compile_multilib: "both",
export_system_include_dirs: ["common_os/include/myinclude"],
target: {
host: {
enabled: false,
},
android: {
export_include_dirs: ["android/include/myinclude-android"],
},
linux_glibc: {
export_include_dirs: ["linux_glibc/include/myinclude-host"],
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_headers {
name: "mysdk_mynativeheaders@current",
sdk_member_name: "mynativeheaders",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
stl: "none",
compile_multilib: "both",
export_system_include_dirs: ["common_os/include/myinclude"],
target: {
host: {
enabled: false,
},
android: {
export_include_dirs: ["android/include/myinclude-android"],
},
linux_glibc: {
export_include_dirs: ["linux_glibc/include/myinclude-host"],
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
host_supported: true,
native_header_libs: ["mysdk_mynativeheaders@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> common_os/include/myinclude/Test.h
myinclude-android/AndroidTest.h -> android/include/myinclude-android/AndroidTest.h
myinclude-host/HostTest.h -> linux_glibc/include/myinclude-host/HostTest.h
`),
)
}
func TestSystemSharedLibPropagation(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["sslnil", "sslempty", "sslnonempty"],
}
cc_library {
name: "sslnil",
host_supported: true,
}
cc_library {
name: "sslempty",
system_shared_libs: [],
}
cc_library {
name: "sslnonempty",
system_shared_libs: ["sslnil"],
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "sslnil",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
arch: {
arm64: {
srcs: ["arm64/lib/sslnil.so"],
},
arm: {
srcs: ["arm/lib/sslnil.so"],
},
},
}
cc_prebuilt_library_shared {
name: "sslempty",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
system_shared_libs: [],
arch: {
arm64: {
srcs: ["arm64/lib/sslempty.so"],
},
arm: {
srcs: ["arm/lib/sslempty.so"],
},
},
}
cc_prebuilt_library_shared {
name: "sslnonempty",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
system_shared_libs: ["sslnil"],
arch: {
arm64: {
srcs: ["arm64/lib/sslnonempty.so"],
},
arm: {
srcs: ["arm/lib/sslnonempty.so"],
},
},
}
`))
result = testSdkWithCc(t, `
sdk {
name: "mysdk",
host_supported: true,
native_shared_libs: ["sslvariants"],
}
cc_library {
name: "sslvariants",
host_supported: true,
target: {
android: {
system_shared_libs: [],
},
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "sslvariants",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
compile_multilib: "both",
target: {
host: {
enabled: false,
},
android: {
system_shared_libs: [],
},
android_arm64: {
srcs: ["android/arm64/lib/sslvariants.so"],
},
android_arm: {
srcs: ["android/arm/lib/sslvariants.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/sslvariants.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/sslvariants.so"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_sslvariants@current",
sdk_member_name: "sslvariants",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
installable: false,
compile_multilib: "both",
target: {
host: {
enabled: false,
},
android: {
system_shared_libs: [],
},
android_arm64: {
srcs: ["android/arm64/lib/sslvariants.so"],
},
android_arm: {
srcs: ["android/arm/lib/sslvariants.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/sslvariants.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/sslvariants.so"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
host_supported: true,
native_shared_libs: ["mysdk_sslvariants@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`))
}
func TestStubsLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["stubslib"],
}
cc_library {
name: "internaldep",
}
cc_library {
name: "stubslib",
shared_libs: ["internaldep"],
stubs: {
symbol_file: "some/where/stubslib.map.txt",
versions: ["1", "2", "3"],
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "stubslib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
stubs: {
versions: [
"1",
"2",
"3",
"current",
],
},
arch: {
arm64: {
srcs: ["arm64/lib/stubslib.so"],
},
arm: {
srcs: ["arm/lib/stubslib.so"],
},
},
}
`))
}
func TestDeviceAndHostSnapshotWithStubsLibrary(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
host_supported: true,
native_shared_libs: ["stubslib"],
}
cc_library {
name: "internaldep",
host_supported: true,
}
cc_library {
name: "stubslib",
host_supported: true,
shared_libs: ["internaldep"],
stubs: {
symbol_file: "some/where/stubslib.map.txt",
versions: ["1", "2", "3"],
},
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "stubslib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
compile_multilib: "both",
stubs: {
versions: [
"1",
"2",
"3",
"current",
],
},
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/stubslib.so"],
},
android_arm: {
srcs: ["android/arm/lib/stubslib.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/stubslib.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/stubslib.so"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_stubslib@current",
sdk_member_name: "stubslib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
installable: false,
compile_multilib: "both",
stubs: {
versions: [
"1",
"2",
"3",
"current",
],
},
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/stubslib.so"],
},
android_arm: {
srcs: ["android/arm/lib/stubslib.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/stubslib.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/stubslib.so"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
host_supported: true,
native_shared_libs: ["mysdk_stubslib@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`))
}
func TestUniqueHostSoname(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
host_supported: true,
native_shared_libs: ["mylib"],
}
cc_library {
name: "mylib",
host_supported: true,
unique_host_soname: true,
}
`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mylib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
unique_host_soname: true,
compile_multilib: "both",
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/mylib.so"],
},
android_arm: {
srcs: ["android/arm/lib/mylib.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/mylib-host.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/mylib-host.so"],
},
},
}
`),
checkVersionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mysdk_mylib@current",
sdk_member_name: "mylib",
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
host_supported: true,
installable: false,
unique_host_soname: true,
compile_multilib: "both",
target: {
host: {
enabled: false,
},
android_arm64: {
srcs: ["android/arm64/lib/mylib.so"],
},
android_arm: {
srcs: ["android/arm/lib/mylib.so"],
},
linux_glibc_x86_64: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86_64/lib/mylib-host.so"],
},
linux_glibc_x86: {
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
enabled: true,
srcs: ["linux_glibc/x86/lib/mylib-host.so"],
},
},
}
sdk_snapshot {
name: "mysdk@current",
visibility: ["//visibility:public"],
host_supported: true,
native_shared_libs: ["mysdk_mylib@current"],
target: {
host: {
enabled: false,
},
Enable sdk and sdk members in os_arch granularity This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change, when there is a member that returns IsHostOsDependent() == true, the sdk having the member and the member itself are disable for host and only the os that the member supports is explicitly enabled. However, that change will cause a problem when we add the support for the linux_bionic_arm64 target. The target is not enabled when building sdk snapshots. The only linux_bionic target that is enabled is 'linux_bionic_x86_64'. However, since the granularity is os which is linux_bionic, the snapshot is generated as follows. cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic: { enabled: true, }, linux_bionic_x86_64: { srcs: ["x86_64/bin/..."], }, // no srcs for linux_bionic_arm64 }, } Above is a problem for linux_bionic_arm64 target because the target is enabled (via linux_bionic.enabled: true), but srcs is not provided. To fix the problem, the enabling of a target is done in a target (os_arch) granularity, rather than os granularity. For example, above now becomes ... cc_prebuilt_binary { target: { host: { enabled: false, }, linux_bionic_x86_64: { enabled: true, srcs: ["x86_64/bin/..."], }, }, } Only the targets that the snapshot actually can provide srcs are enabled and the rest of the host targets are disabled. Bug: 159685774 Test: m nothing Test: build/soong/scripts/build-aml-prebuilts.sh runtime-module-host-exports Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
2020-10-19 21:47:34 +08:00
linux_glibc_x86_64: {
enabled: true,
},
linux_glibc_x86: {
enabled: true,
},
},
}
`),
checkAllCopyRules(`
.intermediates/mylib/android_arm64_armv8-a_shared/mylib.so -> android/arm64/lib/mylib.so
.intermediates/mylib/android_arm_armv7-a-neon_shared/mylib.so -> android/arm/lib/mylib.so
.intermediates/mylib/linux_glibc_x86_64_shared/mylib-host.so -> linux_glibc/x86_64/lib/mylib-host.so
.intermediates/mylib/linux_glibc_x86_shared/mylib-host.so -> linux_glibc/x86/lib/mylib-host.so
`),
)
}
func TestNoSanitizerMembers(t *testing.T) {
result := testSdkWithCc(t, `
sdk {
name: "mysdk",
native_shared_libs: ["mynativelib"],
}
cc_library_shared {
name: "mynativelib",
srcs: ["Test.cpp"],
export_include_dirs: ["myinclude"],
arch: {
arm64: {
export_system_include_dirs: ["arm64/include"],
sanitize: {
hwaddress: true,
},
},
},
}
`)
// Mixing the snapshot with the source (irrespective of which one is preferred) causes a problem
// due to missing variants.
// TODO(b/183204176): Remove this and fix the cause.
snapshotWithSourceErrorHandler := android.FixtureExpectsAtLeastOneErrorMatchingPattern(`\QReplaceDependencies could not find identical variant {os:android,image:,arch:arm64_armv8-a,sdk:,link:shared,version:} for module mynativelib\E`)
CheckSnapshot(t, result, "mysdk", "",
checkUnversionedAndroidBpContents(`
// This is auto-generated. DO NOT EDIT.
cc_prebuilt_library_shared {
name: "mynativelib",
prefer: false,
visibility: ["//visibility:public"],
apex_available: ["//apex_available:platform"],
compile_multilib: "both",
export_include_dirs: ["include/myinclude"],
arch: {
arm64: {
export_system_include_dirs: ["arm64/include/arm64/include"],
},
arm: {
srcs: ["arm/lib/mynativelib.so"],
},
},
}
`),
checkAllCopyRules(`
myinclude/Test.h -> include/myinclude/Test.h
arm64/include/Arm64Test.h -> arm64/include/arm64/include/Arm64Test.h
.intermediates/mynativelib/android_arm_armv7-a-neon_shared/mynativelib.so -> arm/lib/mynativelib.so
`),
snapshotTestErrorHandler(checkSnapshotWithSourcePreferred, snapshotWithSourceErrorHandler),
snapshotTestErrorHandler(checkSnapshotPreferredWithSource, snapshotWithSourceErrorHandler),
)
}