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

Installation with Carthage is broken #55

Open
renatorodrigues opened this issue Sep 27, 2017 · 31 comments
Open

Installation with Carthage is broken #55

renatorodrigues opened this issue Sep 27, 2017 · 31 comments

Comments

@renatorodrigues
Copy link

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.

@devxoul
Copy link
Owner

devxoul commented Sep 28, 2017

Is there any reason to use carthage update with --no-use-binaries option?

@renatorodrigues
Copy link
Author

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.

@devxoul
Copy link
Owner

devxoul commented Sep 29, 2017

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?

@JohnTheBastard
Copy link

I'm having the same issue.

@devxoul
Copy link
Owner

devxoul commented Oct 26, 2017

@JohnTheBastard which error message did you get?

@devxoul
Copy link
Owner

devxoul commented Oct 29, 2017

@hebiao6446, which error message did you get?

@mr-v
Copy link

mr-v commented Nov 2, 2017

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

@tdkn
Copy link

tdkn commented Nov 2, 2017

I'm getting same issue in iOS project.
Is there a way to solve without downgrading? 😭 @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?

@devxoul
Copy link
Owner

devxoul commented Nov 2, 2017

Hey guys, I made a new release (2.2.1) which supports Xcode 9.1 🎉

@ghost
Copy link

ghost commented Dec 6, 2017

Any updates?

@devxoul
Copy link
Owner

devxoul commented Dec 7, 2017

@MortyMerr, which version of Xcode are you using?

@ghost
Copy link

ghost commented Dec 21, 2017

@devxoul 9.2

@m-tatsuto
Copy link

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)."

@intoxicated
Copy link

To support future Xcode updates, I think you need to add back proj file for carthage in order to build with --no-use-binaries

@JJMoon
Copy link

JJMoon commented May 12, 2018

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?

@JJMoon
Copy link

JJMoon commented May 12, 2018

I installed via Pod, which didn't make this error.
Using Carthage is tricky.

@devxoul
Copy link
Owner

devxoul commented May 12, 2018

Hey guys, I just updated the prebuilt binary of the latest release. Please check it again :)

@Igor-Palaguta
Copy link

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

@devxoul
Copy link
Owner

devxoul commented May 16, 2018

@Igor-Palaguta Which version of Xcode are you using?

@Igor-Palaguta
Copy link

Version 9.3 (9E145)

@devxoul
Copy link
Owner

devxoul commented May 17, 2018

@Igor-Palaguta Can you share the swift version?

$ swift --version

@Igor-Palaguta
Copy link

Apple Swift version 4.1 (swiftlang-902.0.48 clang-902.0.37.1)
Target: x86_64-apple-darwin17.3.0

@devxoul
Copy link
Owner

devxoul commented May 19, 2018

@Igor-Palaguta Hmm, that should work. Can you try again after removing Carthage caches?

$ rm -rf ~/Library/Caches/org.carthage.CarthageKit

@sisomollov
Copy link

@devxoul this error occur when --no-use-binaries is used. Carthage needs project file to work.

@valeriyvan
Copy link

valeriyvan commented Jun 27, 2018

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)

@SeRG1k17
Copy link

SeRG1k17 commented Nov 3, 2018

@devxoul Installation via Carthage still no working.

@devxoul
Copy link
Owner

devxoul commented Feb 9, 2019

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 :)

@capnslipp
Copy link
Contributor

@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.

@capnslipp
Copy link
Contributor

capnslipp commented Apr 19, 2019

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.

@capnslipp
Copy link
Contributor

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.

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

Successfully merging a pull request may close this issue.

14 participants