f99b8b5bc4
* baseline * fix clang-tidy * manually revert these files * manually fixup at eof * revert 2 more files * change check_deprecated_grpc++.py * change end2end_defs.include template * fix check_include_guards.py * untrack tools/distrib/python/convert_cstyle_comments_to_cpp.py not yet ready to be submitted * fix yapf check_include_guards.py remove a space... * fix version.cc.template * fix version_info.h.template |
||
|---|---|---|
| .. | ||
| security | ||
| README.md | ||
| async_generic_service.h | ||
| async_stream.h | ||
| async_unary_call.h | ||
| byte_buffer.h | ||
| call.h | ||
| call_hook.h | ||
| call_op_set.h | ||
| call_op_set_interface.h | ||
| callback_common.h | ||
| channel_interface.h | ||
| client_callback.h | ||
| client_context.h | ||
| client_interceptor.h | ||
| client_unary_call.h | ||
| completion_queue.h | ||
| completion_queue_tag.h | ||
| config.h | ||
| config_protobuf.h | ||
| create_auth_context.h | ||
| delegating_channel.h | ||
| intercepted_channel.h | ||
| interceptor.h | ||
| interceptor_common.h | ||
| message_allocator.h | ||
| metadata_map.h | ||
| method_handler.h | ||
| method_handler_impl.h | ||
| proto_buffer_reader.h | ||
| proto_buffer_writer.h | ||
| proto_utils.h | ||
| rpc_method.h | ||
| rpc_service_method.h | ||
| serialization_traits.h | ||
| server_callback.h | ||
| server_callback_handlers.h | ||
| server_context.h | ||
| server_interceptor.h | ||
| server_interface.h | ||
| service_type.h | ||
| slice.h | ||
| status.h | ||
| status_code_enum.h | ||
| string_ref.h | ||
| stub_options.h | ||
| sync.h | ||
| sync_stream.h | ||
| time.h | ||
README.md
Welcome to include/grpcpp/impl/codegen
Why is this directory here?
This directory exists so that generated code can include selected files upon
which it depends without having to depend on the entire gRPC C++ library. This
is particularly relevant for users of bazel, particularly if they use the
multi-lingual proto_library target type. Generated code that uses this target
only depends on the gRPC C++ targets associated with these header files, not the
entire gRPC C++ codebase since that would make the build time of these types of
targets excessively large (particularly when they are not even C++ specific).
What should user code do?
User code should not include anything from this directory. Only generated code
and gRPC library code should include contents from this directory. User code
should instead include contents from the main grpcpp directory or its
accessible subcomponents like grpcpp/support. It is possible that we may
remove this directory altogether if the motivations for its existence are no
longer strong enough (e.g., if most users migrate away from the proto_library
target type or if the additional overhead of depending on gRPC C++ is not high).