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

Carthage build fails when using --use-xcframeworks flag #18

Closed
TobiasKjrsgaard opened this issue Mar 23, 2021 · 5 comments
Closed

Carthage build fails when using --use-xcframeworks flag #18

TobiasKjrsgaard opened this issue Mar 23, 2021 · 5 comments

Comments

@TobiasKjrsgaard
Copy link

As of Carthage 0.37 (January 2021) the recommended way to build frameworks with Carthage and Xcode 12+ is to build a platform-independent XCFramework package (see Carthage README.md).

Our team is working on a MacOS project that uses the SWCompression and are currently trying to migrate to this new way of building our Carthage dependencies in order to get our project ready for its next release.

However, when I run carthage bootstrap --use-xcframeworks --platform macOS --no-use-binaries (using Xcode 12.4 and Carthage 0.37) the build job for the SWCompression project fails with an exit code of 65. Looking at the build log it seems that the SWCompression project is unable to locate and include the BitByteData framework that has been built as an XCFramework package:

/Users/[...]/src/Carthage/Checkouts/SWCompression/Sources/ZIP/ZipEndOfCentralDirectory.swift:7:8: error: no such module 'BitByteData'
import BitByteData
       ^

** ARCHIVE FAILED **


The following build commands failed:
	CompileSwift normal x86_64
	CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
	CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
	CompileSwift normal arm64
(4 failures)

Carthage has checked out the BitByteData project and successfully managed to build it, so it is definitely there, it's just not in the path and/or format that SWCompression expects it to be.

According to the Migration Steps in the Carthage README.md migrating the SWCompression project to use this new format should only require a single step:

For a framework target: In the Build Phases tab, in a Link Binary with Libraries phase, drag and drop each XCFramework you use from the Carthage/Build folder on disk.

@TobiasKjrsgaard
Copy link
Author

The release notes for Carthage 0.37 also seems to provide further details on the problem: https://github.com/Carthage/Carthage/releases/tag/0.37.0

@tsolomko
Copy link
Owner

Yeah, I am somewhat aware of this situation. Since this particular problem is not very exciting to deal with (in my view), and at one point I was very confused by Carthage's documentation about the migration steps, I was hoping that can I avoid doing anything about it for the time being. Apparently, not...

Anyway, I will try to do something about it some time this week.🙂

@tsolomko
Copy link
Owner

tsolomko commented Mar 24, 2021

According to the Migration Steps in the Carthage README.md migrating the SWCompression project to use this new format should only require a single step:

For a framework target: In the Build Phases tab, in a Link Binary with Libraries phase, drag and drop each XCFramework you use from the Carthage/Build folder on disk.

Also, this is not as easy as this instruction, since I have a non-standard setup which is necessary to support multiple darwin platforms (macOS, iOS, etc.) at the same time.

@tsolomko
Copy link
Owner

I've just release a new update, 4.5.8, which should fix this issue.

One caveat though: there is a chance this won't work on macs with M1 processor, but I can't really check this since I have no access to such a device. Please let me know, if you use a M1 mac and you encounter any issues with this.

@TobiasKjrsgaard
Copy link
Author

TobiasKjrsgaard commented Mar 29, 2021

I've just tested the new release on an M1 mac and it works perfectly.

Thank you so much!

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