Add an entry point to xcodeproj rule for overriding project attributes #165
Conversation
|
👀 here in case anyone has any ideas, also bumped into this while working on something else. Found more than one discussion similar to this: bazelbuild/bazel#10414 |
rules/xcodeproj.bzl
Outdated
| @@ -683,8 +683,11 @@ def _xcodeproj_impl(ctx): | |||
| if _is_current_project_file(f) | |||
| ] | |||
|
|
|||
| attributes = {} | |||
| attributes.update(ctx.attr.project_attributes_overrides) | |||
There was a problem hiding this comment.
is there any reason why this can't be passed directly into the struct initializer below?
Eventually (in bazel 4 iirc) there's a module to deserialize JSON, so we could accept a JSON string as the parameter there and serialize an arbitrary data structure to JSON inside a macro which then calls the rule |
There was a problem hiding this comment.
Please let me know if there is a better way so that we can allow customization done easily for downstream projects.
Eventually (in bazel 4 iirc) there's a module to deserialize JSON, so we could accept a JSON string as the parameter there and serialize an arbitrary data structure to JSON inside a macro which then calls the rule
So for now we keep it as is? I just feel with current approach the param list for this rule might explode once we start to need overrides for options or settings or other configs.
rules/xcodeproj.bzl
Outdated
| xcodeproj_info = struct( | ||
| name = paths.split_extension(project_name)[0], | ||
| attributes = attributes, |
There was a problem hiding this comment.
do you mean this?
| attributes = attributes, | |
| attributes = ctx.attr.project_attributes_overrides, |
If so what i have in mind is that the patterm has been have a placeholder at line 686 so we can throw in any default attribute. Also it matches with how things declared for options and settings.
There was a problem hiding this comment.
since ctx.attr.project_attributes_overrides has a default of {}, doing this assignment directly has no harm as well, I will do this after your reply.
yeah it works for now, we can always change it / take a more complicated approach later |
Co-authored-by: Samuel Giddins <[email protected]>
Why this change
Need to provide a way to insert custom attributes for downstream projects
Was thinking about using a
project_overrideswhere one can pass{'attributes': {key: value}, 'options': {key: value}, 'settings' {key: value}}to cover other fields that we have default values for. But according to Bazel doc https://docs.bazel.build/versions/master/skylark/lib/attr.html#string_dict values forstring_dictcan only be string, so have to break them up into individual fields like the change proposed here.Please let me know if there is a better way so that we can allow customization done easily for downstream projects.
Tests
After adding one to a sample project, it indeed gets reflected in the corresponding generated project