The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) https://grpc.io/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

71 lines
2.5 KiB

%YAML 1.2
--- |
// $Id$
// vim:ft=javascript
ARG_WITH("grpc", "grpc support", "no");
if (PHP_GRPC != "no") {
<%
srcs = []
srcs.extend(php_config_m4.src)
lib_maps = {lib.name: lib for lib in libs}
php_deps = php_config_m4.get('deps', [])
php_full_deps = []
for dep in php_deps:
php_full_deps.append(dep)
[build metadata] Bazel to "other build systems" improvements (#33803) - 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.
1 year ago
lib = lib_maps.get(dep, None)
if lib:
php_full_deps.extend(lib.transitive_deps)
# construct list of all source files, but explicitly exclude cares
for dep in set(php_full_deps) - set({'cares'}):
[build metadata] Bazel to "other build systems" improvements (#33803) - 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.
1 year ago
lib = lib_maps.get(dep, None)
if lib:
srcs.extend(lib.src)
srcs = sorted(set(srcs))
%>
EXTENSION("grpc",
% for src in srcs:
"${src.replace('/','\\\\')} " +
% endfor
""
, null,
"/DOPENSSL_NO_ASM /D_GNU_SOURCE /DWIN32_LEAN_AND_MEAN "+
"/D_HAS_EXCEPTIONS=0 /DNOMINMAX /DGRPC_ARES=0 /D_WIN32_WINNT=0x600 "+
"/I"+configure_module_dirname+" "+
"/I"+configure_module_dirname+"\\include "+
5 years ago
"/I"+configure_module_dirname+"\\src\\core\\ext\\upb-generated "+
"/I"+configure_module_dirname+"\\src\\core\\ext\\upbdefs-generated "+
"/I"+configure_module_dirname+"\\src\\php\\ext\\grpc "+
5 years ago
"/I"+configure_module_dirname+"\\third_party\\abseil-cpp "+
"/I"+configure_module_dirname+"\\third_party\\address_sorting\\include "+
"/I"+configure_module_dirname+"\\third_party\\boringssl-with-bazel\\src\\include "+
"/I"+configure_module_dirname+"\\third_party\\re2 "+
5 years ago
"/I"+configure_module_dirname+"\\third_party\\upb "+
[protobuf] Upgrade third_party/protobuf to 22.x (#32606) The very non-trivial upgrade of third_party/protobuf to 22.x This PR strives to be as small as possible and many changes that were compatible with protobuf 21.x and didn't have to be merged atomically with the upgrade were already merged. Due to the complexity of the upgrade, this PR wasn't created automatically by a tool, but manually. Subsequent upgraded of third_party/protobuf with our OSS release script should work again once this change is merged. This is best reviewed commit-by-commit, I tried to group changes in logical areas. Notable changes: - the upgrade of third_party/protobuf submodule, the bazel protobuf dependency itself - upgrade of UPB dependency to 22.x (in the past, we used to always upgrade upb to "main", but upb now has release branch as well). UPB needs to be upgraded atomically with protobuf since there's a de-facto circular dependency (new protobuf depends on new upb, which depends on new protobuf for codegen). - some protobuf and upb bazel rules are now aliases, so ` extract_metadata_from_bazel_xml.py` and `gen_upb_api_from_bazel_xml.py` had to be modified to be able to follow aliases and reach the actual aliased targets. - some protobuf public headers were renamed, so especially `src/compiler` needed to be updated to use the new headers. - protobuf and upb now both depend on utf8_range project, so since we bundle upb with grpc in some languages, we now have to bundle utf8_range as well (hence changes in build for python, PHP, objC, cmake etc). - protoc now depends on absl and utf8_range (previously protobuf had absl dependency, but not for the codegen part), so python's make_grpcio_tools.py required partial rewrite to be able to handle those dependencies in the grpcio_tools build. - many updates and fixes required for C++ distribtests (currently they all pass, but we'll probably need to follow up, make protobuf's and grpc's handling of dependencies more aligned and revisit the distribtests) - bunch of other changes mostly due to overhaul of protobuf's and upb's internal build layout. TODOs: - [DONE] make sure IWYU and clang_tidy_code pass - create a list of followups (e.g. work to reenable the few tests I had to disable and to remove workaround I had to use) - [DONE in cl/523706129] figure out problem(s) with internal import --------- Co-authored-by: Craig Tiller <ctiller@google.com>
2 years ago
"/I"+configure_module_dirname+"\\third_party\\utf8_range "+
"/I"+configure_module_dirname+"\\third_party\\xxhash "+
5 years ago
"/I"+configure_module_dirname+"\\third_party\\zlib ");
<%
dirs = sorted(set(src[:src.rfind('/')] for src in srcs))
dirset = set(dirs)
for dir in dirs:
frags = dir.split('/')
for i in range(1, len(frags)):
dirset.add('/'.join(frags[:i]))
dirs = [d.replace('/', '\\\\') for d in sorted(dirset)]
%>
base_dir = get_define('BUILD_DIR');
FSO.CreateFolder(base_dir+"\\ext");
FSO.CreateFolder(base_dir+"\\ext\\grpc");
% for dir in dirs:
FSO.CreateFolder(base_dir+"\\ext\\grpc\\${dir}");
% endfor
_build_dirs = new Array();
for (i = 0; i < build_dirs.length; i++) {
if (build_dirs[i].indexOf('grpc') == -1) {
_build_dirs[_build_dirs.length] = build_dirs[i];
}
}
build_dirs = _build_dirs;
}