Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applying swift.opt_uses_osize recursively to dependencies #492

Open
michaeleisel opened this issue Sep 16, 2020 · 14 comments
Open

Applying swift.opt_uses_osize recursively to dependencies #492

michaeleisel opened this issue Sep 16, 2020 · 14 comments
Labels
P3 Would be nice, but probably next quarter at the earliest

Comments

@michaeleisel
Copy link
Contributor

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.

@keith
Copy link
Member

keith commented Sep 16, 2020

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

@michaeleisel
Copy link
Contributor Author

michaeleisel commented Sep 16, 2020

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

@keith
Copy link
Member

keith commented Sep 16, 2020

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?

@michaeleisel
Copy link
Contributor Author

they would be built twice

@keith
Copy link
Member

keith commented Sep 16, 2020

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
Copy link
Member

keith commented Sep 16, 2020

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

@michaeleisel
Copy link
Contributor Author

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

@keith
Copy link
Member

keith commented Sep 16, 2020

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

@segiddins
Copy link
Contributor

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

@keith
Copy link
Member

keith commented Sep 16, 2020

how would that setup look?

@segiddins
Copy link
Contributor

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

@keith
Copy link
Member

keith commented Sep 17, 2020 via email

@keith keith reopened this Sep 17, 2020
@segiddins
Copy link
Contributor

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

@keith
Copy link
Member

keith commented Sep 17, 2020

Sorry I meant more for optimization stuff

@keith keith added the P3 Would be nice, but probably next quarter at the earliest label Oct 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Would be nice, but probably next quarter at the earliest
Projects
None yet
Development

No branches or pull requests

3 participants