a8508ec465
- Extract build metadata for some external dependencies from bazel build. This is achieved by letting extract_metadata_from_bazel_xml.py analyze some external libraries and sources. The logic is basically the same as for internal libraries, I only needed to teach extract_metadata_from_bazel_xml.py which external libraries it is allowed to analyze. * currently, the list of source files is automatically determined for `z`, `upb`, `re2` and `gtest` dependencies (at least for the case where we're building in "embedded" mode - e.g. mostly native extensions for python, php, ruby etc. - cmake has the ability to replace some of these dependencies by actual cmake dependency.) - Eliminate the need for manually written gen_build_yaml.py for some dependencies. - Make the info on target dependencies in build_autogenerated.yaml more accurate and complete. Until now, there were some depdendencies that were allowed to show up in build_autogenerated.yaml and some that were being skipped. This made generating the CMakeLists.txt and Makefile quite confusing (since some dependencies are being explicitly mentioned and some had to be assumed by the build system). - Overhaul the Makefile * the Makefile is currently only used internally (e.g. for ruby and PHP builds) * until now, the makefile wasn't really using the info about which targets depend on what libraries, but it was effectively hardcoding the depedendency data (by magically "knowing" what is the list of all the stuff that e.g. "grpc" depends on). * After the overhaul, the Makefile.template now actually looks at the library dependencies and uses them when generating the makefile. This gives a more correct and easier to maintain makefile. * since csharp is no longer on the master branch, remove all mentions of "csharp" targets in the Makefile. Other notable changes: - make extract_metadata_from_bazel_xml.py capable of resolving workspace bind() rules (so that it knows the real name of the target that is referred to as e.g. `//external:xyz`) TODO: - [DONE] ~~pkgconfig C++ distribtest~~ - [DONE} ~~update third_party/README to reflect changes in how some deps get updated now.~~ Planned followups: - cleanup naming of some targets in build metadata and buildsystem templates: libssl vs boringssl, ares vs cares etc. - further cleanup of Makefile - further cleanup of CMakeLists.txt - remote the need from manually hardcoding extra metadata for targets in build_autogenerated.yaml. Either add logic that determines the properties of targets automatically, or use metadata from bazel BUILD. |
||
|---|---|---|
| .bazelci | ||
| .github | ||
| bazel | ||
| cmake | ||
| doc | ||
| etc | ||
| examples | ||
| fuzztest | ||
| include | ||
| spm-core-include | ||
| spm-cpp-include | ||
| src | ||
| summerofcode | ||
| templates | ||
| test | ||
| third_party | ||
| tools | ||
| .bazelignore | ||
| .bazelrc | ||
| .clang-format | ||
| .clang-tidy | ||
| .dockerignore | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitallowed | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .istanbul.yml | ||
| .pylintrc | ||
| .pylintrc-examples | ||
| .pylintrc-tests | ||
| .rspec | ||
| .yapfignore | ||
| .yardopts | ||
| AUTHORS | ||
| BUILD | ||
| BUILDING.md | ||
| CMakeLists.txt | ||
| CODE-OF-CONDUCT.md | ||
| CONCEPTS.md | ||
| CONTRIBUTING.md | ||
| GOVERNANCE.md | ||
| Gemfile | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| MANIFEST.md | ||
| Makefile | ||
| NOTICE.txt | ||
| OWNERS | ||
| PYTHON-MANIFEST.in | ||
| Package.swift | ||
| README.md | ||
| Rakefile | ||
| SECURITY.md | ||
| TROUBLESHOOTING.md | ||
| WORKSPACE | ||
| _metadata.py | ||
| black.toml | ||
| build_autogenerated.yaml | ||
| build_config.rb | ||
| build_handwritten.yaml | ||
| composer.json | ||
| config.m4 | ||
| config.w32 | ||
| gRPC-C++.podspec | ||
| gRPC-Core.podspec | ||
| gRPC-ProtoRPC.podspec | ||
| gRPC-RxLibrary.podspec | ||
| gRPC.podspec | ||
| grpc.bzl | ||
| grpc.def | ||
| grpc.gemspec | ||
| grpc.gyp | ||
| package.xml | ||
| requirements.bazel.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
README.md
gRPC – An RPC library and framework
gRPC is a modern, open source, high-performance remote procedure call (RPC) framework that can run anywhere. gRPC enables client and server applications to communicate transparently, and simplifies the building of connected systems.
| Homepage: | grpc.io |
| Mailing List: | grpc-io@googlegroups.com |
To start using gRPC
To maximize usability, gRPC supports the standard method for adding dependencies to a user's chosen language (if there is one). In most languages, the gRPC runtime comes as a package available in a user's language package manager.
For instructions on how to use the language-specific gRPC runtime for a project, please refer to these documents
- C++: follow the instructions under the
src/cppdirectory - C#/.NET: NuGet packages
Grpc.Net.Client,Grpc.AspNetCore.Server - Dart: pub package
grpc - Go:
go get google.golang.org/grpc - Java: Use JARs from Maven Central Repository
- Kotlin: Use JARs from Maven Central Repository
- Node:
npm install @grpc/grpc-js - Objective-C: Add
gRPC-ProtoRPCdependency to podspec - PHP:
pecl install grpc - Python:
pip install grpcio - Ruby:
gem install grpc - WebJS: follow the grpc-web instructions
Per-language quickstart guides and tutorials can be found in the documentation section on the grpc.io website. Code examples are available in the examples directory.
Precompiled bleeding-edge package builds of gRPC master branch's HEAD are
uploaded daily to packages.grpc.io.
To start developing gRPC
Contributions are welcome!
Please read How to contribute which will guide you through the entire workflow of how to build the source code, how to run the tests, and how to contribute changes to the gRPC codebase. The "How to contribute" document also contains info on how the contribution process works and contains best practices for creating contributions.
Troubleshooting
Sometimes things go wrong. Please check out the Troubleshooting guide if you are experiencing issues with gRPC.
Performance
See the Performance dashboard for performance numbers of master branch daily builds.
Concepts
See gRPC Concepts
About This Repository
This repository contains source code for gRPC libraries implemented in multiple languages written on top of a shared C core library src/core.
Libraries in different languages may be in various states of development. We are seeking contributions for all of these libraries:
| Language | Source |
|---|---|
| Shared C [core library] | src/core |
| C++ | src/cpp |
| Ruby | src/ruby |
| Python | src/python |
| PHP | src/php |
| C# (core library based) | src/csharp |
| Objective-C | src/objective-c |
| Language | Source repo |
|---|---|
| Java | grpc-java |
| Kotlin | grpc-kotlin |
| Go | grpc-go |
| NodeJS | grpc-node |
| WebJS | grpc-web |
| Dart | grpc-dart |
| .NET (pure C# impl.) | grpc-dotnet |
| Swift | grpc-swift |