search

bazel-ios / rules_ios

Bazel rules for building iOS applications and frameworks
Apache License 2.0
276 stars 84 forks source link

Allow consumers to set always_include_developer_search_paths in swift_library #852

Closed thiagohmcruz closed 5 months ago

thiagohmcruz commented 5 months ago

https://github.com/bazelbuild/rules_swift/pull/1162

thiagohmcruz commented 5 months ago

Discussed offline and we agreed that instead of bumping rules_swift in rules_ios it provides a better DX for both consumers and maintainers to simply allow the flag always_include_developer_search_pathsto be set in kwargs and propagated to the swift_library. Letting consumers decide if they want to bump to a newer rules_swift version or not to start setting that flag in their BUILD files.

thiagohmcruz commented 5 months ago

Shouldn't the flag be always_include_developer_search_paths instead of swift_ always_include_developer_search_paths?

@mattrobmattrob From a mixed frameworks perspective I think we should explicitly convey that this is a Swift thing and not Obj-C. Mostly thinking of a rules_ios user that is not aware of all the underlying impl details of the rules and want it to "just work". In that scenario the names used in the API are the main way to interact with the rule set and IMO we should be very explicit here.

Open to change it though in case I am missing something here!

thiagohmcruz commented 5 months ago

I do wonder if we should come up with a general approach for passing rule attributes through to this point vs. a one off flag. Doesn't seem like we have a pattern for it at this point though.

@mattrobmattrob +1, I would still prefer to land this change to unblock ongoing work but I'm open to contribute to an issue/proposal on that. Def something I thought about in the past too while working on the rules.

mattrobmattrob commented 5 months ago

Shouldn't the flag be always_include_developer_search_paths instead of swift_ always_include_developer_search_paths?

@mattrobmattrob From a mixed frameworks perspective I think we should explicitly convey that this is a Swift thing and not Obj-C. Mostly thinking of a rules_ios user that is not aware of all the underlying impl details of the rules and want it to "just work". In that scenario the names used in the API are the main way to interact with the rule set and IMO we should be very explicit here.

Open to change it though in case I am missing something here!

Deleted my comment but wasn't fast enough. I thought you were passing it through to the swift_library with the prefix but realized I was wrong.