Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B buck
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 201
    • Issues 201
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Meta
  • buck
  • Issues
  • #2594
Closed
Open
Issue created Mar 03, 2021 by Lucas Marçal@Lcsmarcal

[Discussion] XCFrameworks Support

Hey peeps. Last week I was taking a look at support XCFramework on Buck, for both build and project commands.

XCFrameworks is a new bundle type that contains a framework per platform, so you can have a framework for iPhoneOS, WatchOS, MacOS, and their respective simulators in the same XCFramework bundle. And now XCFramework is becoming the main way to distribute binaries. In the last version of the Xcode when using the old framework bundle you already get this kind of error:

Building for iOS Simulator, but the linked and embedded framework 'FirebaseCore.framework' was built for iOS + iOS Simulator.

So I needed to take a look at how Buck can support this new framework bundle. And I came to this solution (#2593), which I'm not very happy with and it's still a kinda "hacky" solution.

It's working both for Buck and Xcode, but here are the topics that I'm not very comfortable with that solution:

  • don't know if the PrebuildAppleFramework.java is the right place to do this kind of logic.
  • PrebuiltAppleFramework does not have the CxxPlatform set on the buildTarget property which is used to search for the right framework path inside the XCFramework bundle. So I needed to write this workaround and it's only working because, luckily, the getTransitiveCxxPreprocessorInput function is called before the getSourcePathToOutput.
  • If it's the right decision to extend the PrebuiltAppleFramework rule instead of creating a new one like PrebuiltAppleXCFramework. I had chosen following with the existing one because creating a new one led me to create a lot of code duplication on the project generation step because XCFrameworks and Frameworks are treated the same on Xcode.
Assignee
Assign to
Time tracking