Agones: C++ SDK Cross compilation and testing

[markmandel]

Problem

Our current support for low dependency, cross compilation for the C++ SDK is very poor. Things work on Linux, because of make and not much else. We also have no tests.

Right now, the C++ SDK is built on top of gRPC, which may be adding too many dependencies to be used in a valuable way across platforms?

Code is here: https://github.com/GoogleCloudPlatform/agones/tree/master/sdks/cpp

Requirements

1. Review the current state of cross complication and dependency with gRPC.
2. Review the SDK REST api endpoints, and see if that would be a better fit than connecting via gRPC.
3. Depending on that, prepare a design doc (added here is fine), with the following things in mind:
   
   
   
   1. Ability to cross compile on Linux/Mac/Windows
   
   
   2. Add some kind of unit tests, build tests, etc ideally with automation
   
   
   3. Anything else that is important to the C++ ecosystem (dependencies?)
   
   

Caveat: This is written by @markmandel who has little to no idea about C++ and its ecosystem, so direction on the above is also appreciated.

Research

https://github.com/grpc/grpc/blob/master/src/cpp/README.md#make
https://www.appveyor.com
https://circleci.com/build-environments/xcode/osx/
https://docs.travis-ci.com/user/reference/osx/

History

[SurferJeffAtGoogle]

CMake is the defacto standard for building C and C++ code across platforms.

[markmandel]

Totally happy to have this rewritten with CMake (or whatever is appropriate) - I totally bashed this together with the help of someone with (somewhat?) more C++ experience than me, and this is an ecosystem I am very much not familiar with.

[cyriltovena]

/cc @sylvainduchesne

[dzlier-gcp]

Notes doc after meeting with rennie@, markmandel@ and myself.

[markmandel]

@martin-z-google This is the current state of the C++ SDK situation - please let me know if this makes no sense :smile:

[ortho]

Do you want to run protoc during build phase when using cmake or just want to compile current source using cmake (to make small step to cross building)?

[markmandel]

@ortho I think I understand the question? (I'm not 100% sure)

We generate the code from protoc and store it in our github repo - since it's not going to change. We only change it when the .proto file changes -- and you can run make gen-gameservers-sdk-grpc to regenerate as needed.

Does that answer the question?

[ortho]

Sorry, English is not my native language. :(

Let me try again.

I'm going to close this issue.
There are two ways to make it done.

First way (simplest):
Rewrite sdks/cpp/Makefile to CMake sdks/cpp/CMakeLists.txt

Second way:

1. Remove all *.pb.cc and *.pb.h files in sdks/cpp/**.
2. Create CMake script in sdks/cpp/CMakeLists.txt
3. "Script" try to find protobuf, grpc packages in system (during configure phase).
4. Generate all needed *.pb.cc and *.pb.h files during build phase (without en-grpc-cpp.sh)

Which one would be preferable?

[markmandel]

@ortho - so right now, @martin-z-google is working on the first way. There are still runtime dependencies on protobuf's libraries, outside of the code generation (if i understand correctly, although martin can explain better than I can)

Personally, I'm not seeing any benefit in the second way -- it's not as if the generate code ever changes. But maybe I'm missing something?

[martin-z-google]

FYI pull request is up: https://github.com/GoogleCloudPlatform/agones/pull/421

[dsazonoff]

Are there any requests about linking configuration? Because there is a lot of possible configurations: dynamic SDK + dynamic gRPC; static SDK + dynamic gRPC, static SDK + static SDK etc.
What do you think?

[markmandel]

@alexandrem - do you have opinions here? You are my goto C++ person :smile:

Or should we just get _something_ that works, and then we can iterate from there?

[dsazonoff]

I created a #464 pull request. It contain cmake scripts for cpp SDK.

[roberthbailey]

From the requirements in the initial issue comment, did anyone ever take a look into

1. Review the SDK REST api endpoints, and see if that would be a better fit than connecting via gRPC.

and write up rationale for continuing to invest in the gRPC wrappers?

[dsazonoff]

@roberthbailey I think that we should continue to use gRPC, because it is possible to have connection with most languages (even js). Nginx already supports forwarding of grpc traffic. And it is possible to create some kind of proxy over grpc->http, but I don't see any real cases when we may need it. But I'm not good in this area.

[markmandel]

Was digging through community build steps - found this, thought it might be interesting:
https://github.com/GoogleCloudPlatform/cloud-builders-community/tree/master/windows-builder

[roberthbailey]

@dsazonoff - If the argument is about language support, then pretty much any language you'd encounter today will support sending an HTTP request. And since HTTP is a core part of the language, we don't need to worry about how well / long it is supported or compiler compatibility / etc.

On the server side, I'm all in favor of grpc and http endpoints both being exposed. The question was more along the lines of whether it makes sense for the clients we build to depend on grpc or whether HTTP is sufficient as it is possible a smaller code.

[sylvainduchesne]

Both will work for the work, and admittedly HTTP is simpler to integrate. However, you need to poll for the GameSession status over HTTP, whereas that callback should come in automatically over gRPC.

Personally, I don't find that convenience to be enough to warrant integrating gRPC on the client, since most codebases will already have HTTP clients integrated.