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 #13

Closed
soffes opened this Issue Jan 11, 2017 · 52 comments

Comments

Projects
None yet
@soffes

soffes commented Jan 11, 2017

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

@timburks

This comment has been minimized.

Contributor

timburks commented Jan 11, 2017

Noted - thanks!

@slessans

This comment has been minimized.

slessans commented Feb 13, 2017

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

This comment has been minimized.

noppoMan commented Mar 6, 2017

@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

screen shot 2017-03-06 at 16 45 19

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

Link Binary With Libraries Phase

screen shot 2017-03-06 at 17 16 11

Run Script Phase

screen shot 2017-03-06 at 16 48 18

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

@ebriney

This comment has been minimized.

ebriney commented Jun 22, 2017

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

This comment has been minimized.

noppoMan commented Jun 26, 2017

@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

This comment has been minimized.

ebriney commented Jun 27, 2017

Thanks, I will try that.

@willks

This comment has been minimized.

willks commented Jul 15, 2017

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

@agirault

This comment has been minimized.

agirault commented Oct 5, 2017

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

This comment has been minimized.

shakesVan commented Nov 23, 2017

@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

This comment has been minimized.

MikeSilvis commented Feb 2, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 6, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

@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

This comment has been minimized.

Collaborator

MrMage commented Feb 27, 2018

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

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

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

@MikeSilvis

This comment has been minimized.

MikeSilvis commented Feb 27, 2018

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

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

@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

This comment has been minimized.

MikeSilvis commented Feb 27, 2018

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

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

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

This comment has been minimized.

MikeSilvis commented Feb 27, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

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

This comment has been minimized.

MikeSilvis commented Feb 27, 2018

I have Carthage working, not Cocoapods

@MrMage

This comment has been minimized.

Collaborator

MrMage commented Feb 27, 2018

Did anyone try just removing zlib from the altogether?

@MrMage

This comment has been minimized.

Collaborator

MrMage commented Feb 27, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

@MrMage I just updated the Package.swift file to remove CZlib from the list of dependencies. Turns out, it is still needed for CgRPC:
screen shot 2018-02-27 at 10 57 26 am

@MrMage

This comment has been minimized.

Collaborator

MrMage commented Feb 27, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented Feb 27, 2018

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

This comment has been minimized.

MikeSilvis commented Mar 14, 2018

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

@MrMage

This comment has been minimized.

Collaborator

MrMage commented Mar 14, 2018

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

@willks

This comment has been minimized.

willks commented Mar 27, 2018

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

This comment has been minimized.

Contributor

SebastianThiebaud commented May 27, 2018

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

This comment has been minimized.

Collaborator

MrMage commented May 28, 2018

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

@SebastianThiebaud

This comment has been minimized.

Contributor

SebastianThiebaud commented May 29, 2018

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

This comment has been minimized.

Collaborator

MrMage commented May 29, 2018

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

This comment has been minimized.

Contributor

SebastianThiebaud commented May 29, 2018

I wish, but it doesn't 😞

@JonasVautherin

This comment has been minimized.

Contributor

JonasVautherin commented Aug 6, 2018

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

This comment has been minimized.

Collaborator

MrMage commented Aug 7, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 7, 2018

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

This comment has been minimized.

Collaborator

MrMage commented Aug 7, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 7, 2018

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

  1. I need to run $ make && make project before I can run xcodebuild.
  2. 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

This comment has been minimized.

Collaborator

MrMage commented Aug 7, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 7, 2018

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

This comment has been minimized.

Collaborator

MrMage commented Aug 7, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 14, 2018

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

@JonasVautherin

This comment has been minimized.

Contributor

JonasVautherin commented Aug 21, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 21, 2018

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

This comment has been minimized.

Collaborator

MrMage commented Aug 22, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Aug 22, 2018

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

This comment has been minimized.

Collaborator

MrMage commented Aug 22, 2018

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

@MrMage MrMage closed this Aug 22, 2018

MrMage added a commit to MrMage/grpc-swift that referenced this issue Oct 16, 2018

First experiments with a NIO-based gRPC server.
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

This comment has been minimized.

sbarow commented Nov 6, 2018

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

This comment has been minimized.

Contributor

JonasVautherin commented Nov 7, 2018

@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

This comment has been minimized.

Collaborator

MrMage commented Nov 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment