devxoul / Then

✨ Super sweet syntactic sugar for Swift initializers
MIT License
4.16k stars 290 forks source link

Installation with Carthage is broken #55

Open renatorodrigues opened 6 years ago

renatorodrigues commented 6 years ago

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 commented 6 years ago

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

renatorodrigues commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

I'm having the same issue.

devxoul commented 6 years ago

@JohnTheBastard which error message did you get?

devxoul commented 6 years ago

@hebiao6446, which error message did you get?

mr-v commented 6 years ago

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 commented 6 years ago

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?

devxoul commented 6 years ago

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

ghost commented 6 years ago

Any updates?

devxoul commented 6 years ago

@MortyMerr, which version of Xcode are you using?

ghost commented 6 years ago

@devxoul 9.2

m-tatsuto commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

devxoul commented 6 years ago

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

Igor-Palaguta commented 6 years ago

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 commented 6 years ago

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

Igor-Palaguta commented 6 years ago

Version 9.3 (9E145)

devxoul commented 6 years ago

@Igor-Palaguta Can you share the swift version?

$ swift --version
Igor-Palaguta commented 6 years ago

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

devxoul commented 6 years ago

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

$ rm -rf ~/Library/Caches/org.carthage.CarthageKit
sisomollov commented 6 years ago

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

valeriyvan commented 6 years ago

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 commented 5 years ago

@devxoul Installation via Carthage still no working.

devxoul commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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.