SKYLARK DESIGN REVIEW - Skylark Build Configuration

[Greg Estren]

This was already shared on bazel-discuss, but I'm also sharing here to fulfill the Skylark design review process.

This is for proposed Skylark build configuration.

[Julie Xia]

Update: Adding an additional proposal to this design. This proposal drills down into the API of parameterized skylark-defined transitions. 

[Greg Estren]

FYI, my current suggestion for the Parameterized Transitions API (and in response to the concerns on that doc):

a) parameterized rule class transitions are as powerful as parameterized attribute transitions: Given a transition on "deps' that reads attribute "foo" to determine what to do, you can model this with a rule class transition that reads "foo" to set some other field "bar", then apply a (non-parameterized) attribute transition on "deps" that reads "bar" to figure out what to do.

That was a lot of words. Let's try this visually:

Before:

my_rule(

    name = "myrule",

    srcs = ["myrule.in"]  # this should build without any transition

    deps = [":mydep"],    # applies a split transition that sets "--define what=" to whatever attribute foo says

    foo = "dothis")       # this determines what to split to. This attribute might also have a select().

my_rule(

    name = "mydep",

    srcs = ["mydep.in"])   # should build with "--define what=dothis"

After:

my_rule(                  # applies a rule class transition that sets "--bar=" to whatever attribute foo says

    name = "myrule",

    srcs = ["myrule.in"]  # this builds as before since "--bar" isn't used by the rule

    deps = [":mydep"],    # applies a non-parameterized split transition that sets "--define what=--bar"

    foo = "dothis")

my_rule(

    name = "mydep",

    srcs = ["mydep.in"])   # should build with "--define what=dothis"

b) given this equivalence plus the paucity (first time I've used that word in a while) of actual use cases for parameterized attribute transitions, the argument for supporting them is poor. Epecially since it creates all the API complexity we're witnessing in Parameterized Transitions API. So I see API complexity plus a lack of value for that complexity.

c) the big blocker to all the above is that attribute transitions work on attributes with select(), while rule class transitions don't.

d) but rule class transitions still have access to a configuration that can be used to resolve selects: the parent's configuration.

e) so long as the rule transition doesn't try to write an attribute that's also read by one of the selects, the parent's and child's configurations are interchangeable w.r.t. the transition. So it's safe to slap a ConfiguredAttributeMapper on the attribute with the parent's configuration.

f) if the transition does try to read a forbidden attribute, we can simply fail with an error. Since I'm not aware of a single use case that would actually trigger this error, this seems like a reasonable corner case to fail on for the benefit of all the simplicity benefits described above.

Some of us are planning to sync on Friday to move forward on this, so I wanted to get my ideas out before then. If anyone reading wants to be a part of that sync and isn't please let us know!

[Julie Xia]

After syncing today, I've added a new proposal here in the doc. Generally it simplifies the transition implementation signature to one signature (with some caveats...). PTAL!

[mst...@google.com]

(cross-posted from bazel-discuss)

Here are some thoughts about merging config_feature_flag with Starlark build configuration, to reduce redundancy:

https://docs.google.com/document/d/1kfZ2fQPY32fbjoCpzF2bFMoidhjVtkTmgW-6Zhxwhqk/edit?usp=sharing

[Julie Xia]

Here are some updated thoughts on rule transitions and configurable attributes! 

https://docs.google.com/document/d/1MDbxk21nti40uoMzt7h02213086KtEb2T_WEKVmMjuQ/edit?usp=sharing

TL;DR - rule transitions happen before configurable attributes (select()s) get resolved == problems

On Thursday, April 12, 2018 at 1:00:30 PM UTC-4, Greg Estren wrote: