Avoid generating a CompileAssetCatalog build phase #43
Conversation
tests/xcodeproj/Single-Application-Project.xcodeproj/project.pbxproj
Outdated
Show resolved
Hide resolved
rules/xcodeproj.bzl
Outdated
| "group": paths.dirname(s.short_path), | ||
| "optional": True, | ||
| } | ||
| if ".xcassets" in s.path: |
There was a problem hiding this comment.
do we actually maybe want to filter out everything that would go into the PBXResourcesBuildPhase, instead of only asset catalogs?
There was a problem hiding this comment.
I wasn't sure how to figure out what all these possible things were, but I would have preferred to do that.
There was a problem hiding this comment.
Take a look at _bucketize in https://github.com/bazelbuild/rules_apple/blob/9c1e460ec08af6e36673d6c6f34c723b09ae9328/apple/internal/resources.bzl -- I think everything explicitly called out there (e.g. not "unprocessed") could be ignore.
Another approach would be to propagate 2 different fields in the provider -- one for explicit srcs that come from the srcs attribute and another with basically everything else. Everything not in srcs would get added without a build phase. That's probably the more elegant way of handling this, rather than hardcoding based on extensions
…plists, asset catalogs, etc.) Continue to load those files into the xcode project.
3e2292f to
9212352
Compare
There was a problem hiding this comment.
I consider this as a super important PR I am going to keep referring to because it bridges a concept well known (asset catalog) to the existing framework we have and it has tests that shows how each component link together. (a very important PR to study for any newbie)
| @@ -31,7 +31,6 @@ def _xcodeproj_aspect_impl(target, ctx): | |||
| test_commandline_args = () | |||
| if AppleBundleInfo in target: | |||
There was a problem hiding this comment.
I am trying to understand this if stmt because the code change applies to all blocks of this if stmts correct?
there are
AppleBundleInfo in targetctx.rule.kind == "apple_framework_packaging"else
I wonder each is for what cases?
There was a problem hiding this comment.
In practice:
if AppleBundleInfo in targetis generally applied to targets that are unit test bundles or application bundles.- When the target is packaged up framework (this target usually depends on the components of a framework, like libraries, resource bundles, plists.)
- Everything else. If the target is not performing a bundling/packaging operation, it often contains some kind of source files and dependencies with their source files.
|
Sorry for the late review, but LGTM |
For xcasset sources, we do not want xcode to run actool. I'm not sure how to stub out the CompileAssetCatalog command, so it's easier to just load xcasset files into the xcodeproject, but not associate them with any build phase.