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-11 21:17:01 +02:00
|
|
|
// Copyright 2020 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// 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 android
|
|
|
|
|
|
|
|
import (
|
|
|
|
"reflect"
|
|
|
|
"testing"
|
|
|
|
)
|
|
|
|
|
|
|
|
func Test_mergeApexVariations(t *testing.T) {
|
2020-11-02 18:32:38 +01:00
|
|
|
const (
|
|
|
|
ForPrebuiltApex = true
|
|
|
|
NotForPrebuiltApex = 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-11 21:17:01 +02:00
|
|
|
tests := []struct {
|
|
|
|
name string
|
|
|
|
in []ApexInfo
|
|
|
|
wantMerged []ApexInfo
|
|
|
|
wantAliases [][2]string
|
|
|
|
}{
|
|
|
|
{
|
|
|
|
name: "single",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
|
|
|
{"foo", "apex10000"},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "merge",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo", "bar"},
|
|
|
|
InApexModules: []string{"foo", "bar"},
|
|
|
|
}},
|
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-11 21:17:01 +02:00
|
|
|
wantAliases: [][2]string{
|
2022-04-21 17:13:45 +02:00
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex10000"},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "don't merge version",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: uncheckedFinalApiLevel(30),
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "apex30",
|
|
|
|
MinSdkVersion: uncheckedFinalApiLevel(30),
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex30"},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "merge updatable",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"foo", "bar"},
|
|
|
|
InApexModules: []string{"foo", "bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex10000"},
|
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-11 21:17:01 +02:00
|
|
|
},
|
|
|
|
},
|
2020-11-02 18:32:38 +01:00
|
|
|
{
|
|
|
|
name: "don't merge when for prebuilt_apex",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
2020-11-02 18:32:38 +01:00
|
|
|
// This one should not be merged in with the others because it is for
|
|
|
|
// a prebuilt_apex.
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "baz",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"baz"},
|
|
|
|
InApexModules: []string{"baz"},
|
|
|
|
ForPrebuiltApex: ForPrebuiltApex,
|
|
|
|
},
|
2020-11-02 18:32:38 +01:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"foo", "bar"},
|
|
|
|
InApexModules: []string{"foo", "bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "baz",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
Updatable: true,
|
|
|
|
InApexVariants: []string{"baz"},
|
|
|
|
InApexModules: []string{"baz"},
|
|
|
|
ForPrebuiltApex: ForPrebuiltApex,
|
|
|
|
},
|
2020-11-02 18:32:38 +01:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex10000"},
|
2020-11-02 18:32:38 +01:00
|
|
|
},
|
|
|
|
},
|
2021-06-22 13:23:05 +02:00
|
|
|
{
|
2022-04-12 05:23:20 +02:00
|
|
|
name: "merge different UsePlatformApis but don't allow using platform api",
|
2021-06-22 13:23:05 +02:00
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
UsePlatformApis: true,
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
2021-06-22 13:23:05 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
InApexVariants: []string{"foo", "bar"},
|
|
|
|
InApexModules: []string{"foo", "bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
2021-06-22 13:23:05 +02:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
2022-04-12 05:23:20 +02:00
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex10000"},
|
2022-04-12 05:23:20 +02:00
|
|
|
},
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "merge same UsePlatformApis and allow using platform api",
|
|
|
|
in: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "foo",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
UsePlatformApis: true,
|
|
|
|
InApexVariants: []string{"foo"},
|
|
|
|
InApexModules: []string{"foo"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
ApexVariationName: "bar",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
UsePlatformApis: true,
|
|
|
|
InApexVariants: []string{"bar"},
|
|
|
|
InApexModules: []string{"bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
2022-04-12 05:23:20 +02:00
|
|
|
},
|
|
|
|
wantMerged: []ApexInfo{
|
2024-04-16 00:32:38 +02:00
|
|
|
{
|
|
|
|
ApexVariationName: "apex10000",
|
|
|
|
MinSdkVersion: FutureApiLevel,
|
|
|
|
UsePlatformApis: true,
|
|
|
|
InApexVariants: []string{"foo", "bar"},
|
|
|
|
InApexModules: []string{"foo", "bar"},
|
|
|
|
ForPrebuiltApex: NotForPrebuiltApex,
|
|
|
|
},
|
2022-04-12 05:23:20 +02:00
|
|
|
},
|
|
|
|
wantAliases: [][2]string{
|
2021-06-22 13:23:05 +02:00
|
|
|
{"foo", "apex10000"},
|
2024-04-16 00:32:38 +02:00
|
|
|
{"bar", "apex10000"},
|
2021-06-22 13:23:05 +02:00
|
|
|
},
|
|
|
|
},
|
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-11 21:17:01 +02:00
|
|
|
}
|
2020-11-02 18:32:38 +01:00
|
|
|
|
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-11 21:17:01 +02:00
|
|
|
for _, tt := range tests {
|
|
|
|
t.Run(tt.name, func(t *testing.T) {
|
2024-04-16 00:32:38 +02:00
|
|
|
gotMerged, gotAliases := mergeApexVariations(tt.in)
|
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-11 21:17:01 +02:00
|
|
|
if !reflect.DeepEqual(gotMerged, tt.wantMerged) {
|
|
|
|
t.Errorf("mergeApexVariations() gotMerged = %v, want %v", gotMerged, tt.wantMerged)
|
|
|
|
}
|
|
|
|
if !reflect.DeepEqual(gotAliases, tt.wantAliases) {
|
|
|
|
t.Errorf("mergeApexVariations() gotAliases = %v, want %v", gotAliases, tt.wantAliases)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|