rules_swift icon indicating copy to clipboard operation
rules_swift copied to clipboard

Applying swift.opt_uses_osize recursively to dependencies

Open michaeleisel opened this issue 5 years ago • 14 comments

Typically when my co-workers and I are picking between -O and -Osize, we think about it at the app level and not the module level. If one wants to use -Osize, they would generally want to use it everywhere and not just for specific modules. However, it seems like when this feature is applied to a swift rule, it only affects that rule, and not its recursive dependencies. It would be nice to have some way for the feature to propagate to them.

michaeleisel avatar Sep 16 '20 21:09 michaeleisel

You should pass --feature=swift.opt_uses_osize in your .bazelrc or something instead of adding them in the features = [], array

keith avatar Sep 16 '20 21:09 keith

this would apply globally though, no? which would include apps that we want to use -O for

michaeleisel avatar Sep 16 '20 21:09 michaeleisel

If you had 2 apps, one that wanted this and one that didn't, and they shared dependencies, and you built both at the same time, what flags would the shared dependencies get? or would you build them twice?

keith avatar Sep 16 '20 21:09 keith

they would be built twice

michaeleisel avatar Sep 16 '20 21:09 michaeleisel

I don't think bazel has the ability to do this kinda thing 🤔 without maybe creating a macro that created 2 underlying rules, one for each config

keith avatar Sep 16 '20 21:09 keith

For us passing the top level feature works because we never build multiple prod versions of the app in the same invocation

keith avatar Sep 16 '20 21:09 keith

i see, yeah i guess invocation level will do what i want. i just didn't want .bazelrc since then it would apply across multiple invocations. i think it's an adequate solution

michaeleisel avatar Sep 16 '20 21:09 michaeleisel

Yea makes sense. I do think there's room for a bazel improvement here

keith avatar Sep 16 '20 21:09 keith

I don't think bazel has the ability to do this kinda thing 🤔 without maybe creating a macro that created 2 underlying rules, one for each config

This is exactly what configuration transitions are for

segiddins avatar Sep 16 '20 22:09 segiddins

how would that setup look?

keith avatar Sep 16 '20 22:09 keith

It doesn't work with features (they don't propagate down), but you could define a starlark build flag that's used in a transition and then read in a rule implementation

segiddins avatar Sep 16 '20 23:09 segiddins

I wonder if any other languages solve this in bazel?

keith avatar Sep 17 '20 01:09 keith

It's how things like CPU and deployment target are propagated for C++/Swift.

segiddins avatar Sep 17 '20 01:09 segiddins

Sorry I meant more for optimization stuff

keith avatar Sep 17 '20 01:09 keith