Carthage Support #13

soffes · 2017-01-11T17:24:20Z

It would be fantastic if you had Carthage support with pre-built binaries ❤️

timburks · 2017-01-11T17:37:08Z

Noted - thanks!

slessans · 2017-02-13T03:35:34Z

Any insight into how to do this would be greatly appreciated -- currently having lots of trouble trying to use this library from an iOS application.

noppoMan · 2017-03-06T07:59:10Z

@timburks @soffes
Hi, I tried to install grpc-swift via Carthage and it worked fine on my iPhone 7 plus.
(I also successfully archived/exported(ipa) and installed from ad-hoc with following flows)

Cartfile

github "apple/swift-protobuf" "0.9.24"
github "grpc/grpc-swift" "0.1.10"

and execute carthage update --platform iOS

Adding Header Search Paths for CgRPC

$(SRCROOT)/Carthage/Checkouts/grpc-swift/Sources/CgRPC/include

Link Binary With Libraries Phase

Run Script Phase

Check this out If you are interested.
Actually I'm gonna use grpc-swift on my both of server and iOS project!

ebriney · 2017-06-22T15:53:13Z

But there is no mac target though:

*** Skipped building grpc-swift due to the error:
Dependency "grpc-swift" has no shared framework schemes for any of the platforms: Mac

If you believe this to be an error, please file an issue with the maintainers at https://github.com/grpc/grpc-swift/issues/new

noppoMan · 2017-06-26T07:42:59Z

@ebriney
Currently grpc-swift does not have .xcodeproj cause this is a SPM library. (It means this is not be able to install via Carthage)
If you wanna install this with Carthage, folk this and add xcodeproj with swift package generate-xcodeproj.

Or Try this https://github.com/noppoMan/grpc-swift
It has a xcodeproj that include some extra settings for iOS building and can install via Carthage.

ebriney · 2017-06-27T07:59:26Z

Thanks, I will try that.

willks · 2017-07-15T05:30:51Z

@noppoMan Thanks for your fork - I'm using it and it's very easy to get going thanks to the Carthage support! Cheers

agirault · 2017-10-05T18:17:42Z

Or Try this https://github.com/noppoMan/grpc-swift

@noppoMan: it seems @timburks showed interest. Therefore, would it make sense to create a PR with the xcodeproj to allow to use Carthage out of the box? Would that package the headers to avoid adding the CgRPC include directory to the Header Search Paths ?

shakesVan · 2017-11-23T07:43:38Z

@noppoMan Thank you.
Cartfile

github "apple/swift-protobuf"
github "grpc/grpc-swift"

execute carthage update --platform iOS
I can't get grpc frameworks. Do you know why?

MikeSilvis · 2018-02-02T00:51:16Z

@timburks any update on this? It would help immensely for developing iOS apps

SebastianThiebaud · 2018-02-06T00:30:27Z

I would love to see Carthage support for grpc-swift. Any update on this? I'd love to help if needed.

SebastianThiebaud · 2018-02-27T06:36:17Z

@timburks We got a working fork for Carthage, but that implies some changes if we want the main repository https://github.com/grpc/grpc-swift to support Carthage. I don't know what's your position about supporting Carthage but I'd strongly encourage to enable it (more adoption of grpc-swift can only lead to a better quality of the library and more hands to help). I could help to get grpc-swift ready for Carthage. The only blocker that I see at the moment is related to CZlib. The dependency used (https://github.com/ZewoGraveyard/CZlib) wouldn't work at this point with Carthage. I also realized that this dependency hasn't been updated for over 2 years. Could we assume it won't be updated anymore and directly include the source code in this repository? If that's not something that seems good to you, we could make CZlib working with Carthage too.

MrMage · 2018-02-27T09:41:43Z

Would another option be to simply avoid including zlib in your Carthage spec? For example, in my grpc-swift Podspec I include the necessary dependencies as other Pods instead of using any of the SPM packages or the vendored code. Given that zlib should be available on the Carthage-supported platforms anyway, maybe that would be another option?

Actually, thinking more about this, is the zlib dependency still needed at all? With a cursory look through the framework, I can't find any code dependencies on zlib.

SebastianThiebaud · 2018-02-27T18:13:45Z

If we can confirm that zlib isn't needed, that would be great.

MikeSilvis · 2018-02-27T18:20:45Z

@SebastianThiebaud check out https://github.com/noppoMan/grpc-swift

Using this fork, i was able to get grpc-swift to compile using Carthage

SebastianThiebaud · 2018-02-27T18:22:54Z

@MikeSilvis This repo isn't having the latest changes for almost a year. I'm talking about having the official repository supporting Carthage. Like my initial message mentions, I already got a personal fork working with Carthage.

MikeSilvis · 2018-02-27T18:28:04Z

Yes, i'm just confused as to what the blocker with CZlib is. Here is my own internal fork i use, and i have czlip compiling fine: https://github.com/mikeSilvis/grpc-swift/

SebastianThiebaud · 2018-02-27T18:30:11Z

My point is that the CZlib repository used as dependency isn't compatible with Carthage. Cocoapods and Carthage do not require the same configuration.

MikeSilvis · 2018-02-27T18:34:14Z

@SebastianThiebaud i highly suggest you checkout my fork and try using it with Carthage. I have CZLib working.

SebastianThiebaud · 2018-02-27T18:36:39Z

Yes, I saw that you're using CZlib as a submodule. It is a possibility. Like I said, I already have a working version of this repo working with Carthage (include CZlib). Now, I'm having this discussion here to feel what's the best implementation that I could propose for Carthage so everyone is happy. Since you got Carthage support working for this repository, did you submit a PR for it?

MikeSilvis · 2018-02-27T18:40:27Z

I have Carthage working, not Cocoapods

MrMage · 2018-02-27T18:40:32Z

Did anyone try just removing zlib from the altogether?

MrMage · 2018-02-27T18:41:10Z

@SebastianThiebaud see #139. No mention of zlib whatsoever.

SebastianThiebaud · 2018-02-27T18:44:07Z

Good to know @MrMage. I will try something a bit later today then.

SebastianThiebaud · 2018-02-27T18:57:40Z

@MrMage I just updated the Package.swift file to remove CZlib from the list of dependencies. Turns out, it is still needed for CgRPC:

MrMage · 2018-02-27T19:11:22Z

Damn. Could you try using the system-provided zlib copy, though? (Linked with -lz)

SebastianThiebaud · 2018-02-27T19:14:21Z

I will try this. Another limitation I just remembered: the way libs files (CgRPC, BoringSSL...) are included in the Xcode project is hard to maintain. swift package generate-xcodeproj can create the project and add the necessary files but Carthage needs a project file committed with a shared scheme.

MikeSilvis · 2018-03-14T22:25:44Z

@MrMage @SebastianThiebaud any update on this? I see that Cocoapods support was added

MrMage · 2018-03-14T22:30:01Z

I have a commit that removes the vendored zlib code (Timing-GmbH@263e66b). However, I don't use Carthage, so no idea what else would need to be done to get this usable for Carthage.

willks · 2018-03-27T06:12:34Z

I'm tired of the manual tinkering - so I just swapped back to cocoapods. Not my preference, but I find I have a lot more coding time as opposed to build time issues (and script failures) with Carthage.

Waiting for Swift Package Manager once those lazy ass Apple guys do something about it for iOS.

SebastianThiebaud · 2018-05-27T22:46:13Z

If you're interested, we're maintaining a branch for Carthage in a fork. https://github.com/postmates/grpc-swift/tree/carthage_structure

We've also updated the Makefile so the Xcode project doesn't need any manual operation to work with Carthage. https://github.com/postmates/grpc-swift/blob/carthage_structure/Makefile

MrMage · 2018-05-28T08:16:54Z

Interesting! Do you think there would be a way to merge this upstream to give users the choice between CocoaPods and Carthage?

SebastianThiebaud · 2018-05-29T03:50:09Z

I don't see any way to support Carthage if we don't commit the .xcodeproj file. And I believe we do not want to do this because of SPM, correct?

MrMage · 2018-05-29T06:51:45Z

Does Carthage offer a "pre-build" step? In that case, could we have a "pre-build" script that has SPM generate the project on the fly and, if necessary, patches in the necessary scheme files?

SebastianThiebaud · 2018-05-29T16:40:42Z

I wish, but it doesn't 😞

JonasVautherin · 2018-08-06T23:15:28Z

Why is it not possible to support both the .xcodeproj and SPM? Isn't it what RxSwift is doing? They have both Rx.xcodeproj and Package.swift at the root of the repo. Or did I miss something?

MrMage · 2018-08-07T08:20:22Z

At that point we'd need to ensure that the Carthage .xcodeproj is always kept up-to-date. I am open to this, as long as that work can be done automatically. E.g. by having a script that auto-generates an .xcodeproj via SPM, renames it (to avoid conflicts with the regular SPM one), then applies Carthage-related patches and commits the result.

JonasVautherin · 2018-08-07T11:56:22Z

Right, I played a bit more with it, and it is not so straightforward. Especially because I am building for iOS. So I'll give up on Carthage for now.

MrMage · 2018-08-07T12:03:07Z

What extra complications does building for iOS cause in this case? We are interested in improving the developer experience using SwiftGRPC on iOS, so maybe there are some thing we can improve on here.

JonasVautherin · 2018-08-07T12:47:36Z

I have, I believe, two main issues for Carthage (note: I am on tag 0.4.2).

I need to run $ make && make project before I can run xcodebuild.
Not all the gRPC-Swift targets can be built for iOS: building manually, I run something like $ xcodebuild -target BoringSSL -target SwiftGRPC -target SwiftProtobuf -target CgRPC ... -sdk iphoneos, because when running $ xcodebuild -alltargets -sdk iphoneos, it fails to build.

I read a lot on the Carthage issues/discussions, and I don't believe they would be open to add a possibility to have a "prebuild script" (in this case $ make && make project) that would be run by Carthage. Which means that either gRPC-Swift would need to version the files created by $ make && make project, which is really not convenient, or I would need to fork gRPC-Swift to do it, and that's not much better (but still okay, I guess).

And more importantly, I don't think Carthage is planning to add a way to select which targets to build. There have been many discussions, people have been wanting that for years, have been arguing and all, so I would not count on that anytime soon.

It feels like Carthage works well when you have an .xcodeproj, can build all the schemes for all platforms from that directly and expect your clients to depend on all your schemes. But you don't have any more control than that, so for a repo like gRPC-Swift, it just becomes painful to use/maintain. So I will stay with Cocoapods and my manual scripts for people not wanting to use Cocoapods :-).

MrMage · 2018-08-07T12:51:45Z

Thanks for the elaboration!

As I mentioned before, I might be okay with maintaining a versioned variant of the .xcodeproj under a different name as long as that project could be generated automatically, e.g. before committing. In theory, we could adapt the script that generates that project to automatically delete all non-Carthage targets using the Ruby xcodeproj gem (we already use it to adjust tab widths in make project).

JonasVautherin · 2018-08-07T13:10:42Z

Yeah but at some point, if Carthage requires hacks everywhere in the project, I am not sure if it is really worth it.

For instance, what are "non-Carthage" targets? Maybe people actually want to build all targets for macOS, and only iOS depends solely on BoringSSL, SwiftGRPC, CgRPC and SwiftProtobuf.

MrMage · 2018-08-07T15:03:52Z

I think the things that need to built for Carthage are identical on iOS and Mac (the ones you named). For the rest, we can keep asking users to clone the repo separately and use SPM. With CocoaPods, they also need to clone the repo and build the protoc plugin with SPM, we could adopt the same for Carthage.

Depends on how many hacks would be needed to make the Carthage project work, of course. My stance is more like "If a Carthage users wants this so badly that they would build it the way I described above, then we can probably accomodate for it". I'm not going to go out and build it for them right now ;-)

JonasVautherin · 2018-08-14T15:24:02Z

I believe this issue can be closed now! :-)

JonasVautherin · 2018-08-21T11:14:38Z

Well, actually it doesn't work (see here) 😞.

It works for the simulator, but there seems to be a signing problem somewhere that I don't understand.

JonasVautherin · 2018-08-21T17:44:03Z

I was not using Carthage's copy-framework in the project depending on Carthage! So it actually works.

Here is an example project that works with grpc-swift! I also have 2 other projects where people have been able to use the Carthage integration, so I would say it is finally working 🎉.

MrMage · 2018-08-22T06:53:57Z

Sorry, is this still working? ;-)

I noticed some changes between "working" and "not working"; please let me know if everything is working now and whether we need to update some code or documentation on the SwiftGRPC side for full Carthage compatibility.

JonasVautherin · 2018-08-22T08:32:53Z

It is working.

I thought it was not, but it was my fault as a Carthage user, and not a bug in the SwiftGRPC setup.

And now I have other developers who have been using it in other projects and who confirmed that it works for them :-).

MrMage · 2018-08-22T08:33:47Z

Thanks for the heads-up! Closing this; let me know (or file a new issue) in case you do encounter problems in the future.

Contains the following commits: - Refactor gRPC decoding into dedicated codec classes. - Start work on GRPCServerHandler. - Add a "unary call handler" and use that for the tests. - Refactoring starting a GRPC server into a dedicated class. - Fix sending unary responses. - Add a handler for client-streaming calls. - Also implement bidirectional-streaming calls. - Make sure to flush in server-streaming calls after each sent message. - Add the missing test cases to `allTests`. - Refactor `StatusSendingHandler` into its own class. - Rename `GRPCServerHandler` to `GRPCChannelHandler`. - Remove a FIXME. - Add a few more comments. - Attach the actual call handlers as channel handlers instead of manually forwarding messages to them. # This is the commit message grpc#2: Remove SwiftGRPCNIO's dependency on SwiftGRPC and move the responsibility for encoding GRPC statuses to HTTP1ToRawGRPCServerCoded. # This is the commit message grpc#3: Temporarily disable two test cases that are failing at the moment. # This is the commit message grpc#4: Add SwiftGRPCNIO as an exposed library. # This is the commit message grpc#5: Another try at getting CI to work with SwiftGRPCNIO. # This is the commit message grpc#6: More dependency fixes. # This is the commit message grpc#7: Add `SwiftGRPCNIO.EchoServerTests` to LinuxMain.swift. # This is the commit message grpc#8: Fix a string comparison in `.travis-install.sh`. # This is the commit message grpc#9: Add nghttp2 to the list of CI dependencies. # This is the commit message grpc#10: Another try with installing nghttp2 via brew. # This is the commit message grpc#11: Another try at using libnghttp2-dev under Ubuntu 14.04. # This is the commit message grpc#12: More Travis fixes. # This is the commit message grpc#13: One last try. # This is the commit message grpc#2: Disable two more tests for now, as they sometimes fail on CI. # This is the commit message grpc#3: Make Carthage debug builds verbose. # This is the commit message grpc#4: Only use SwiftGRPC-Carthage.xcodeproj for Carthage builds.

sbarow · 2018-11-06T17:39:52Z

Is this task resolved and is Carthage officially supported now? Not able to get this to build using carthage update --platform iOS

Carthage: 0.31.2
Tried with:
github "grpc/grpc-swift" "23a0ebdee9613f615f2f2469ed3e700df5856417"
github "grpc/grpc-swift" "0.6.0"
github "grpc/grpc-swift" "0.5.1"

JonasVautherin · 2018-11-07T18:12:13Z

@sbarow: Are you on Xcode 10?

Somehow it doesn't build with Xcode 10, and I haven't understood why yet. Xcode 9.4.1 works, though. I'm not sure what Xcode 10 is doing but it somehow changes the path = ".build/checkouts/swift-protobuf.git-<hash> in the project file and then doesn't find it -_-.

MrMage · 2018-11-07T18:16:02Z

@JonasVautherin could it be that the paths generated by `swift resolve` are different for Xcode 10 vs. 9.4? Or maybe Xcode 10/Swift 4.2 simply doesn't generate deterministic paths for the dependencies, while 9.4/Swift 4.1 does? That would also explain why I never was able to create a working Carthage project for the NIO branch.

…

On 7. Nov 2018, at 19:12, Jonas Vautherin ***@***.***> wrote: @sbarow: Are you on Xcode 10? Somehow it doesn't build with Xcode 10, and I haven't understood why yet. Xcode 9.4.1 works, though. I'm not sure what Xcode 10 is doing but it somehow changes the path = ".build/checkouts/swift-protobuf.git-<hash> in the project file and then doesn't find it -_-. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

makdharma added the kind/enhancement Improvements to existing feature. label Jun 28, 2017

JonasVautherin mentioned this issue Aug 9, 2018

Enable carthage #282

Merged

maznikoff mentioned this issue Aug 17, 2018

Segmentation fault: 11 #280

Closed

MrMage closed this as completed Aug 22, 2018

sbarow mentioned this issue Nov 7, 2018

Carthage not working for 0.5.1 & 0.6.0 #329

Closed

Carthage Support #13

Carthage Support #13

Comments

soffes commented Jan 11, 2017

timburks commented Jan 11, 2017

slessans commented Feb 13, 2017

noppoMan commented Mar 6, 2017 • edited Loading

Adding Header Search Paths for CgRPC

Link Binary With Libraries Phase

Run Script Phase

ebriney commented Jun 22, 2017

noppoMan commented Jun 26, 2017

ebriney commented Jun 27, 2017

willks commented Jul 15, 2017

agirault commented Oct 5, 2017 • edited Loading

shakesVan commented Nov 23, 2017 • edited Loading

MikeSilvis commented Feb 2, 2018

SebastianThiebaud commented Feb 6, 2018

SebastianThiebaud commented Feb 27, 2018

MrMage commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

MikeSilvis commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

MikeSilvis commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

MikeSilvis commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018 • edited Loading

MikeSilvis commented Feb 27, 2018

MrMage commented Feb 27, 2018

MrMage commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

MrMage commented Feb 27, 2018

SebastianThiebaud commented Feb 27, 2018

MikeSilvis commented Mar 14, 2018

MrMage commented Mar 14, 2018

willks commented Mar 27, 2018

SebastianThiebaud commented May 27, 2018 • edited Loading

MrMage commented May 28, 2018

SebastianThiebaud commented May 29, 2018

MrMage commented May 29, 2018

SebastianThiebaud commented May 29, 2018

JonasVautherin commented Aug 6, 2018

MrMage commented Aug 7, 2018

JonasVautherin commented Aug 7, 2018

MrMage commented Aug 7, 2018

JonasVautherin commented Aug 7, 2018

MrMage commented Aug 7, 2018

JonasVautherin commented Aug 7, 2018

MrMage commented Aug 7, 2018

JonasVautherin commented Aug 14, 2018

JonasVautherin commented Aug 21, 2018

JonasVautherin commented Aug 21, 2018

MrMage commented Aug 22, 2018

JonasVautherin commented Aug 22, 2018

MrMage commented Aug 22, 2018

sbarow commented Nov 6, 2018

JonasVautherin commented Nov 7, 2018

MrMage commented Nov 7, 2018 via email

noppoMan commented Mar 6, 2017 •

edited

Loading

agirault commented Oct 5, 2017 •

edited

Loading

shakesVan commented Nov 23, 2017 •

edited

Loading

SebastianThiebaud commented Feb 27, 2018 •

edited

Loading

SebastianThiebaud commented May 27, 2018 •

edited

Loading