Before this cl, blueprint expressions were evaluated as they were
parsed. We want to add a feature to select statements where we can
bind the value of soome value from soong into a blueprint variable,
that then can be used like a regular variable in the .bp file. This
means that select statements need to hold whole unevalated expression
trees, and have the ability to evaluate them later on when the value
of the bound variable is known.
This cl doesn't implement the new select syntax, but it does split
blueprint's parsing and evaluating into two separate stages. We also
store expressions in selects and evaluate them when the select is
resolved.
I didn't do extensive performance evaluation, but a simple comparison
of the time of `touch Android.bp && m nothing` before/after this cl
showed a 1 second speedup. (That was probably just noise)
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I12f373719991afeb4aec76517153f32229d97ff2
This exported function allows soong code to append to configurable
properties.
Bug: 346922064
Test: m nothing --no-skip-soong-tests
Change-Id: Iaadcb1874ef5b972f1eeeb59b317e140ad01c947
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
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
This adds support for selecting on multiple variables at once, so that
you can do AND/OR combindations of them. For example:
select((
arch(),
os(),
), {
("arm64", "linux"): ["libfoo64"],
(default, "linux"): ["libfoo"],
(default, "windows"): ["libfoowindows"],
(default, default): ["libbar"],
})
It also allows for select conditions to be boolean-typed. You can
write literal true and false without quotes to select on them. Currently
we don't have any boolean-typed variables though, so a fake one was
added for testing.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Ibe586e7b21865b8734027848cc421594cbd1d8cc
Part of the design of property structs is that they were easy to access.
In keeping with that spirit, use a shorter and easier to spell name
for the getter, and add GetDefault() so that you don't need to pass
the result of Get() to one of the
proptools.StringDefault/BoolDefault/etc functions.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: Ib9a69dcf2ab56a758935a461f37fe46bc0e17e27
If a property is a pointer to a bool/string, that property would be
replaced instead of appended to when calling ExtendProperties().
This is confusing behavior, and I don't want to give anyone any reason
to use a pointer to a configurable property, so add this relflection
tag to recreate the functionality.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I6b9e4dfee1d2685e0c9dc6a646cf45724cc04756
Currently, with the arch/os mutator, you can override a property
using the default value for just a few arch types, for example:
cc_defaults {
name: "my_defaults",
target: {
windows: {
enabled: true,
}
}
}
cc_binary {
name: "foo",
enabled: false,
defaults: ["my_defaults"],
}
You could make a select statment that acts like the above if it were
all in one module, but currently with select statements you can't make
a defaults module that can be generically applied to any other module
and have the same behavior as the above.
After this cl, the defaults module could look like:
cc_defaults {
name: "my_defaults",
enabled: select(variant("arch"), {
"windows": true,
_: unset,
}),
}
Which would have the same behavior. Unset may also be useful for
setting the property under some configurations, but wanting to leave
the implementation-specific default value in others.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I3ea3277ea8b9a0ac5e613b4378945388b9df036a
This is to match how (non-pointer) booleans work in AppendProperties().
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I16791fc5ac684eedf8064a65953b8b68f18c37c1
...and pass property name to ConfigurableEvaluator.
When trying to convert Enabled to a configurable property, I enountered
a bunch of different context types that all had different error methods.
OtherModulePropertyErrorf is an error method that can be implemented
by all contexts.
Bug: 323382414
Test: m nothing --no-skip-soong-tests
Change-Id: I38b2a545c0ee8d23281cd88bc397f79f39835bc4
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
