Blueprint bootstraps itself, go 1.22 will be used, but if you used
go build or go test manually, the version in the go.mod will be used.
Go 1.22 has a subtle change that we want to make sure we're always
using: https://go.dev/blog/loopvar-preview
Test: Presubmits
Change-Id: I192dbcba16f431458dfb758c505a63027cdb2533
This will be used by soong config value variables to support their
usage on configurable properties.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I20b8ef29e81512548ecdc056533700a30fa7815a
Previously, Configurable.Get() copied the value in the property,
because it needed to return a pointer in order to indicate whether
the property was set or not. Now, it returns a ConfigurableOptional[T],
which is the same as the pointer, but it prevents users from altering
the pointed-to value, so we don't need to copy it.
There are still copies for slice properties, because those are also
pointers. In the future we may want to consider making an ImmutableList
type to use instead.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Ic9ed5ba269d10158e3eac1fea272555c9fa5c0e8
Preivously it attempted to print all conditions and their values,
but that doesn't tell you which one was wrong, and the formatting was
all weird due to trying to print complex go types.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: If9653796f5e9139c0b4a7843b441eb0409967b55
The input variationMap in applyTransitions may be nil, initialize
it if necessary.
Bug: 319288033
Test: TestPostTransitionDeps
Flag: NONE
Change-Id: I091aa5a04732fdf18931b2534c4c479152c2a9e1
* changes:
Don't sort the results of TransitionMutator.Split
Apply outgoing transitions when adding dependencies
Delete transition variation when no matching variant was found
The ordering of variants can be significant when adding
inter-variant dependencies, as a variant can only depend on earlier
variants. Allow maintaining the existing variant ordering when
converting mutators to TransitionMutator by keeping the ordering
of TransitionMutator.Split. Variations that were requested by
incoming dependencies that are not present in Split are still
sorted, as they have no inherent ordering.
Bug: 319288033
Test: TestPostTransitionDeps
Flag: NONE
Change-Id: I648ef95f08a05f9a64ce97e6a39bae10ce88771a
TransitionMutators can always return "" from OutgoingVariation in
order to implement the equivalent of CreateLocalVariations - a
variation that doesn't affect which variation of dependencies is
selected. The same need applies when creating the dependency after
the TransitionMutator. Call OutgoingVariation on the parent module
when adding new dependencies unless the variation was explicitly
requested.
Bug: 319288033
Test: TestPostTransitionDeps
Flag: NONE
Change-Id: Iadb72a5a3f19579a6c1d34e3c7169ee9e2b53210
TransitionMutators sometimes apply to one variant of a module but
not to another. Deleting the variation when all variants were
untouched is insufficient if a post-mutator dependency is being added
on a variant that was untouched. Delete the variation whenever
no matching incoming variant was found.
Bug: 319288033
Test: TestPostTransitionDeps
Flag: NONE
Change-Id: Ib073f6ec3090d09e4798b6f9ca3061ec5d58d722
ReplaceDependencies[If] currently replaces dependencies on a given
module with the current module. It expects to find a variant of the
given module that has the exact same variations as the current module.
That was sometimes handled via aliases, but TransitionMutators don't
support aliases, they use IncomingTransition to rewrite the variation
instead.
In all current usages of ReplaceDependencies[If], the given module
is also a direct dependency of the current module. Instead of looking
for the exact same variations, look for the variant that is a dependency
of the current module.
Bug: 319288033
Test: all soong tests pass
Flag: NONE
Change-Id: I3e33111322040b187f6e951554366ccdcaf1bc11
When adding a dependency on a module that has already had variants
created by a TransitionMutator, ignore any variation added by the
TransitionMutator to the current module if the TransitionMutator
didn't apply to the target module. This requires passing in the
list of variations requested by the AddVariationDependencies call
so that explicitly requested variations are not ignored.
This fixes TestAndroidTest_FixTestConfig when the override mutator
is converted to a TransitionMutator, as it can't add a dependency from
the "foo_test" module with an empty override variation to the
"foo" module that has no override variation.
Bug: 319288033
Test: TestAndroidTest_FixTestConfig
Flag: NONE
Change-Id: If0fca7adc28cd702f953885aef440a0805ac017c
TransitionMutator's top down mutator is suffixed with _deps, but
that name is often used by other mutators related to the
TransitionMutator, causing unexpected conflicts. Use _propagate
instead.
Bug: 319288033
Test: all soong tests pass
Flag: NONE
Change-Id: Ib42c66288e47287cfda8252d435f86c7045bf4c0
In order to do less cloning, refactor selects so that all the
soong-visibile structs are immutable to soong and can be reused.
Additionally, refactor how the inner linked list of selects is managed,
so that the append/prepend/replace logic is simpler.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Iba5d27405decc1b0596590c3e0555daeb044bf9e
The biggest issue here is that Configurable objects needed to be
cloned before appended to one another, otherwise some Configurables
that were used in defaults could be edited after being applied to one
module and apply a different value to another module.
Also fix an issue where a select without a defined appendWrapper
always evaluated to nil.
I plan to make a followup refactor cl to make these things clearer,
but start with the bugfix.
Bug: 323382414
Test: m nothing --no-skip-soong-tests (see other cl in topic for tests)
Change-Id: Icf68d0ee1779c76bfb3d68db43b35d7e09bc0dd9
Sometimes modules add arch-variant properties in load hooks, to disable
modules by default on certain platforms for example. When changing the
property to a Configurable property, these load hooks would also need
to be changed in order to have a matching type for
ExtendMatchingProperties.
Since this can be kindof a pain to address everywhere, for now,
special case the extension functions to promote non-configurable
properties to configurable ones. We can remove this later when
everything switches to configurable properties.
Bug: 323382414
Test: go tests
Change-Id: Iac96587dbd60ccdd6aa667dd69a71ad252abe589
Some soong code sets arch-variant properties in order to control a
module's default behavior. I'll make this continue to work, but long
term the arch-variant properties should be replaced with selects,
so expose an API for creating select statements in soong code.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6c65d6e112b6f826f1027777b6fdf36915d34b1d
Adding a dependency on a module that has already had a TransitionMutator
run on it may require adjusting the variation name based on the results
of IncomingTranstion. Store the variants that existed before the
TransitionMutator ran, find one that is a subset of the requested
variant, and call TranstionMutator.IncomingTransition to update the
value.
Bug: 319288033
Test: TestPostTransitionDeps
Change-Id: I690357f9792401a3edbc5ae9fdcb666495954fbc