Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

static.framework is not completely treated as a framework by Xcode when building #1030

Open
fedetrim opened this issue Feb 24, 2021 · 3 comments

Comments

@fedetrim
Copy link

I'm trying to have a project with mixed ObjC-Swift modules, using static frameworks.

I created a project.yml that describes:

  • An app target with dependency on ModuleA and ModuleB
  • ModuleA static framework with both Swift and ObjC code, with a dependency on ModuleB
  • ModuleB static framework with both Swift and ObjC code

However, it seems like ModuleA and ModuleB are being treated as libraries with respect to some regards, with for example the generated interface <module-name>-Swift.h not being copied to the expected Products path (<ModuleName>.framework/Headers), and instead being copied to DerivedSource (just like it happens with static libraries) and so Xcode fails to find it with this error:
Screen Shot 2021-02-24 at 10 26 56

When taking a look at the build log, it becomes clear that the generated interface is being created, but being copied to DerivedSources instead of the expected <ModuleName>.framework/Headers:
Screen Shot 2021-02-24 at 10 39 39

If I remove the target generated by XcodeGen and create it from scratch using Xcode (as a dynamic framework but then manually change Mach-O type to static, specify modulemap, and then change embed to Do Not Embed in the app target), then everything works fine, and the copy path for the generated interface is the right one:
Screen Shot 2021-02-24 at 10 43 30

Also for some reason the icon shown in the build log is different. With the Xcode-created target, the icon is the framework one 🧳 (the suitcase), but with XcodeGen the icon is the target one 🎯 (not sure if this actually means anything...)

Also, when navigating to the Products folder, I noticed that the <ModuleName>.swiftmodule for the Xcode-created target is generated within the framework, however with the XcodeGen one, it's created outside of it:

Xcode-created target:
Screen Shot 2021-02-24 at 11 21 19

XcodeGen-created target:
Screen Shot 2021-02-24 at 11 21 50

Here's how the project.yml looks like:

name: XcodegenTest
options:
  bundleIdPrefix: com.xcodegentest
  deploymentTarget:
    iOS: "14.0"
  minimumXcodeGenVersion: 2.18.0
  usesTabs: false
  indentWidth: 4
  tabWidth: 4
  xcodeVersion: 12.0
targets:
  XcodegenTest:
    type: application
    platform: iOS
    info:
      path: App/Info.plist
    sources:
      - path: App
    dependencies:
      - target: ModuleA
      - target: ModuleB
  ModuleA:
    type: framework.static
    platform: iOS
    info:
      path: ModuleA/Info.plist
    sources:
      - path: ModuleA
    settings:
      MODULEMAP_FILE: ModuleA/ModuleA.modulemap
    dependencies:
      - target: ModuleB
  ModuleB:
    type: framework.static
    platform: iOS
    info:
      path: ModuleB/Info.plist
    sources:
      - path: ModuleB
    settings:
      MODULEMAP_FILE: ModuleB/ModuleB.modulemap

And this is the attached sample project:
XcodegenTest.zip

@jschear
Copy link

jschear commented Mar 24, 2021

I hit this same issue, and ended up working around it by using the framework product type and setting the MACH_O_TYPE build setting to staticlib manually.

@fedetrim
Copy link
Author

@jschear Thanks for the tip! What about linking? I think the app target should not embed the static frameworks. I think we also have to change that manually within Xcode

@jschear
Copy link

jschear commented Mar 26, 2021

That's my understanding too (that frameworks containing static libraries should not be embedded in app bundles). I believe this recent PR made that XcodeGen's default behavior: #1003

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants