-
-
Notifications
You must be signed in to change notification settings - Fork 727
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 support #262
Carthage support #262
Conversation
Hello @darrenclark Thank you very much! I'm very looking forward to merge this PR.
Tests pass: https://travis-ci.org/groue/GRDB.swift/builds/285813421 What is the next step? Shouldn't we wait for @swiftlyfalling? He did all the hard work bringing custom SQLite builds to GRDB, and his opinion is very valuable to me. |
You're welcome! Sounds good re: getting @swiftlyfalling's opinion on this. |
@darrenclark: Very nice. Previously, SQLiteLib worked with @groue: I merged the PR into |
All right, I carry on. Many thanks, for both your analysis and work! |
@swiftlyfalling Ahhh, I was wondering what was causing the difference between Xcode and xcodebuild, good to know about the No problem, thank you & swiftlyfalling for your work on GRDB! |
Hello @darrenclark, On top of your improvements, I'm adding a few tests that check that frameworks built with Carthage can actually be included in applications. This work in progress is in the development branch. For the context, I want you to understand why GRDB does not currently support Carthage. It is because I could never achieve reliable Carthage builds. Carthage has a build process that makes it very hard to reproduce errors. The Carthage team is cruelly under-staffed, and can't provide efficient support, on a topic that is difficult (Xcode mastery is not an easily found skill). Support to end users has thus to be provided by third-party libraries like GRDB. Since I don't know anyone that could reliably provide good support for GRDB users that open Carthage-related issues, my choice was eventually to remove Carthage from the supported installation methods, and stop worrying about it. I could not resist writing a rant just before I made this decision (it looks like I had a bad day, since my tone is not very nice). After this shift, it was no longer GRDB that would not support Carthage. Instead, from now on, it is Carthage that does not support GRDB, and I'm perfectly fine with this way of thinking about it. Now Carthage build errors are not always due to Carthage, as your PR shows. You do bring a new hope. But if GRDB has improved, thanks to you, Carthage is still the same. We're not quite there yet: I still sometimes get an error when Carthage builds the GRDB frameworks. This reminds me of the days before I decided that this wasn't my problem any longer. For example:
It looks like the initial build always succeed, but further builds sometimes end with an error. When they do, they fail on a random framework: make distclean # Restore repo to pristine state
make test_CarthageBuild # Could not make it fail yet
make test_CarthageBuild # Sometimes OK, sometimes ends in error What do you think? |
Ah I see, makes a lot of sense! And totally understandable why Carthage isn't supported. I'll do a little more fiddling around over the weekend and see if I turn up anything regarding the random failures. |
Yes, @darrenclark, I'm not against a little more help before Carthage doors are opened again. Whatever the results of your investigations, your improvements to sqlcipher and custom SQLite builds will be merged in: consider your PR accepted. Welcome to GRDB contributors! Even if Carthage remains "not officially supported", so that I can avoid the burden of providing support for a flaky installation method, it will be "more" available to die-hard hackers who are ready to spend their own time fixing bizarre build errors. |
@darrenclark I'm about to ship the next GRDB version with your enhancements included, @swiftlyfalling's updated SQLiteLib, and still no "official" Carthage support. I'll close this PR then. Should you eventually grab more information, I'll happily discuss with you again, in a new issue or pull request. Again, thanks a lot for your contribution, and happy GRDB! |
v2.1.0 has shipped. |
@groue sounds good! I haven't had a chance to dig into it a little further yet, but will keep you updated if I eventually discover anything. |
Carthage support
Depends on:
Basic gist of it was, Xcode &
xcodebuild
seemed to have slightly different behavior when it comes to building theamalgamation
target in those submodules:xcodebuild
would run the run script build phase as if it was being built for whatever SDK was specified on the command lineSince the
configure
script &Makefile
rely on building & running an executable as part of the build process, builds viaxcodebuild
would fail (issues related to trying to run an iOS executable on a Mac).With the changes in the above PRs,
make test_CarthageBuild
seems to be working locally for me, so wanted to give it a run on Travis.Due to the nature of this PR (updating submodules to my own forks) I don't think it can be merged as is, I just wanted to verify that everything was passing on Travis