CocoaPods 1.11.x changed the path where xcframework was copied

[rooque]

• I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

I had a scenario as drawn below:

• One pod depends on the other's xcframework
• The Pod that adds these xcframeworks has the dynamic name
• In version 1.10.x the xcframeworks were copied to the folder XCFrameworkIntermediates/${FrameworkName}, it was possible to use the configuration s.pod_target_xcconfig = { "FRAMEWORK_SEARCH_PATHS" => " \"${PODS_XCFRAMEWORKS_BUILD_DIR}/FrameworkA\" \"${PODS_XCFRAMEWORKS_BUILD_DIR}/FrameworkB\"" }, everything works fine.
• In version 1.11.x xcframeworks are copied to XCFrameworkIntermediates/${PodName} folder, making it impossible to use the previous configuration.

This change was probably made by the PR #10884

Is this type of change considered breaking?

Maybe I'm using this configuration in the wrong way and I have some other way to meet this scenario

What did you do?

Pod install and build project for both versions.

What did you expect to happen?

The project should build for both version.

What happened instead?

In 1.10.x -> Project builds just fine.
In 1.11.x -> FrameworkA/FrameworkA.h not found.

Stack

1.10.1

   CocoaPods : 1.10.1
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin20]
    RubyGems : 3.0.3
        Host : macOS 11.4 (20F71)
       Xcode : 12.5 (12E262)
         Git : git version 2.30.1 (Apple Git-130)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.5.0
cocoapods-try         : 1.2.0

1.11.2

   CocoaPods : 1.11.2
        Ruby : ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin20]
    RubyGems : 3.0.3
        Host : macOS 11.4 (20F71)
       Xcode : 12.5 (12E262)
         Git : git version 2.30.1 (Apple Git-130)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib
Repositories : trunk - CDN - https://cdn.cocoapods.org/

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.4
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.5.0
cocoapods-try         : 1.2.0

Project that demonstrates the issue

Ping me if you need this test project

[dnkoutso]

Probably not considered breaking as these are implementation details of how cocoapods works with respect to integrating xcframeworks.

I do not think relying on this mechanism is safe to do so as it can change as it did on 1.11.x.

The reason the paths changed was due to fix another bug as you pointed out. If you rely on pod_target_xcconfig you could update it to be recursive perhaps.

I am curious why you need that setting to begin with?

[rooque]

I need this scenario because PodA will become an open-source library, so who will be responsible for adding the frameworks will be the owner of the project that is using PodA. And since who will add is the project owner, PodB can differentiate the name from project to project.

Is there a better way to do this?

Also, can you demonstrate how it would be the recursive way? Appreciate!

[dnkoutso]

I think you can do "FRAMEWORK_SEARCH_PATHS" => "\"${PODS_XCFRAMEWORKS_BUILD_DIR}/FrameworkA/**\""

I am sorry but I do not quite understand the use case you are trying to accomplish entirely

[rooque]

I think you can do "FRAMEWORK_SEARCH_PATHS" => "\"${PODS_XCFRAMEWORKS_BUILD_DIR}/FrameworkA/**\""

I am sorry but I do not quite understand the use case you are trying to accomplish entirely

This way you showed is how it works in version 1.10.X but not in 1.11.x

Because now in 1.11.x the PODS_XCFRAMEWORKS_BUILD_DIR looks like this:

XCFrameworkFolder/
---PodA/
---PodB/

In 1.10.x it was like:

XCFrameworkFolder/
---FrameworkA/
---FrameworkB/

[dnkoutso]

@rooque maybe I dont quite understand it fully. Either way, I honestly do not think relying on this mechanism is right thing to do.

Would love to hear more about how your use case can be accomplished in a different more appropriate way by cocoapods.