devxoul
Installation with Carthage is broken
Because the repository doesn't contain a .xcodeproj, Carthage is unable to build the framework, failing silently.
Output when running carthage update --platform iOS --no-use-binaries with a clean workspace:
*** Cloning Then
*** Checking out Then at "2.2.0"
*** xcodebuild output can be found in /var/folders/s0/tjb6sjmd3914dzy5mncptr700000gn/T/carthage-xcodebuild.3bko6H.log
The building step is missing from the log. After the last line, there should be another one with the following:
*** Building scheme "Then" in Then.xcodeproj
I've reproduced this with Carthage 0.25 and 0.24.
I prefer to use --no-use-binaries to avoid binaries built with previous versions of Swift, which sometimes are incompatible. Also, it is useful when you need to debug a framework.
I removed Then.xcodeproj from the repository to manage the project only with Swift Package Manager. If you'd like to use with --no-use-binaries, can you try 2.1.1 instead?
Is there any reason to use carthage update with --no-use-binaries option?
Using precompiled version is problematic even with Xcode updates. Xcode 9.1 uses Swift 4.0.2 and importing 4.0 binary is impossible.
Module compiled with Swift 4.0 cannot be imported in Swift 4.0.2
I'm getting same issue in iOS project. Is there a way to solve without downgrading? :sob: @devxoul
$ carthage update Then --platform 'iOS'
*** Fetching Then
*** Downloading Then.framework binary at "2.2.0"
*** Skipped installing Then.framework binary due to the error:
"Incompatible Swift version - framework was built with 4.0 (swiftlang-900.0.65.2 clang-900.0.37) and the local version is 4.0.2 (swiftlang-900.0.69.2 clang-900.0.38)."
*** Checking out Then at "2.2.0"
*** xcodebuild output can be found in /var/folders/h1/s2z3h3c51_g8bcm5z8z8bjjc0000gn/T/carthage-xcodebuild.Dy77Zu.log
Or should I use SwiftPM?
I'm getting same issue in iOS project. Xcode 9.2 Apple Swift version 4.0.3
github "devxoul/Then"
% carthage update --platform iOS Then
...
*** Downloading Then.framework binary at "2.3.0"
*** Skipped installing Then.framework binary due to the error:
"Incompatible Swift version - framework was built with 4.0.2 (swiftlang-900.0.69.2 clang-900.0.38) and the local version is 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)."
To support future Xcode updates, I think you need to add back proj file for carthage in order to build with --no-use-binaries
I installed Channel.io which includes Then framework with Carthage. It makes many issues, but finally I got an issue which says.
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: -extract armv7 specified but fat file: /Users/moin/Library/Developer/Xcode/DerivedData/moinRemit-etdanftfmfxyjmbasmgxhsnyearp/Build/Intermediates.noindex/ArchiveIntermediates/appname/InstallationBuildProductsLocation/Applications//appRaemri.app/Frameworks/Then.framework/Then does not contain that architecture
And I added 'run script' in http://ikennd.ac/blog/2015/02/stripping-unwanted-architectures-from-dynamic-libraries-in-xcode/.
How can I solve this problem?
I installed via Pod, which didn't make this error. Using Carthage is tricky.
Hey guys, I just updated the prebuilt binary of the latest release. Please check it again :)
The same issue was on 2.3.0
*** Checking out Then at "2.3.0"
*** xcodebuild output can be found in /var/folders/4k/dzpnw8352jn_fl5hcc76pjs8k9qytq/T/carthage-xcodebuild.diNH6z.log
*** Skipped building Then due to the error:
Dependency "Then" has no shared framework schemes for any of the platforms: iOS
If you believe this to be an error, please file an issue with the maintainers at https://github.com/devxoul/Then/issues/new
Just works version 2.1.0 with xcodeproj
Apple Swift version 4.1 (swiftlang-902.0.48 clang-902.0.37.1) Target: x86_64-apple-darwin17.3.0
@Igor-Palaguta Hmm, that should work. Can you try again after removing Carthage caches?
$ rm -rf ~/Library/Caches/org.carthage.CarthageKit
@devxoul this error occur when --no-use-binaries is used. Carthage needs project file to work.
carthage update Then --platform iOS
...
*** Skipped installing Then.framework binary due to the error:
"Incompatible Swift version - framework was built with 4.1 (swiftlang-902.0.48 clang-902.0.37.1) and the local version is 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)."
*** Skipped building Then due to the error:
Dependency "Then" has no shared framework schemes for any of the platforms: iOS
If you believe this to be an error, please file an issue with the maintainers at https://github.com/devxoul/Then/issues/new
carthage update Then --platform iOS --no-use-binaries
...
*** Skipped building Then due to the error:
Dependency "Then" has no shared framework schemes for any of the platforms: iOS
If you believe this to be an error, please file an issue with the maintainers at https://github.com/devxoul/Then/issues/new
That's for both 2.1.0 and 2.3.0.
swift --version
Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)
Target: x86_64-apple-darwin17.6.0
Xcode Version 9.4.1 (9F2000)
I'd prefer to keep this repository as simple as possible. Carthage requires extra work. (maintaining Xcode projects) It seems that Carthage is going to support SPM-only project from Swift 5 so we better wait for it :)
@devxoul I see where you're going with trying to keep things simple, but you haven't just broken Carthage support by removing Then.xcodeproj— you've broken no-dependency-manager direct-usage support as well. It's perfectly valid to clone an open-source lib and add it to your xcodeproj as a sub-project. Now that Then no longer has its own xcodeproj, it is no longer possible to add Then as a subproject building its own static lib or dynamic framework. Without an xcodeproj, the only option is to add Then's source code directly to one's project directly, combining it into the same binary— which is really a step backwards in technology by about 20 years and has many drawbacks.
I understand you're hopeful for the future and what newer versions of the Swift toolchain could bring. But we're not there yet. And we won't be there until Xcode has a GUI integration for adding and managing SPM-based dependencies. Until Xcode supports SPM directly (without build phase scripts or a whole bunch of command-line work up-front), Then.xcodeproj will be necessary. Please re-add it until Apple themselves have decided that SPM is mature enough to warrant a full integration with Xcode.
Put another way, my current solution for my project is:
carthage update --no-build
cd Carthage/Checkouts/Then/
swift package generate-xcodeproj
ruby -e "
require 'xcodeproj'
project = Xcodeproj::Project.open 'Then.xcodeproj'
project.build_configurations.map(&:name).each do |config_name|
project.build_settings(config_name)['MACOSX_DEPLOYMENT_TARGET'] = '10.9'
project.build_settings(config_name)['IPHONEOS_DEPLOYMENT_TARGET'] = '8.0'
project.build_settings(config_name)['TVOS_DEPLOYMENT_TARGET'] = '9.0'
project.build_settings(config_name)['WATCHOS_DEPLOYMENT_TARGET'] = '2.0'
end
project.save
"
cd -
carthage build
That sucks.
Not to beat the dead horse here, but I just wanted to pop back in because I've been working to update some of my open source frameworks for the latest Swift version and consequently, the latest Swift Package Manager.
And O.M.G. … Swift Package Manager is a steaming hot mess. I can't even understand how anybody would consider this to be anything but Alpha-quality. Package(…) arguments that change both in what's allowed and in types allowed every year, dumb auto-assumptions that have no docs explaining them and no search results (i.e. if you have a .modulemap in your library's base directory, the library is auto-assumed to be a system package, which is no longer supported), crap backwards-compatibility (many of my libs support Swift 3.0-5.1, but the swiftLanguageVersions: option no longer has an enum case for .v3), and much much more.
Long story short— no matter what you've read from who, Swift Package Manager needs a lot of work before it could even remotely be considered as an alternative to Carthage or Cocoapods. Software maturity takes time & effort, and SPM is a malnourished infant. My personal advice to every other dev reading this is: Don't bother with Swift Package Manager. I stand by what I said before— when Apple has decided that SPM is mature enough to be integrated into Xcode, it may be worth another look, but until SPM isn't good enough for Apple's Xcode team it isn't good enough for me, and it shouldn't be good enough for you either.