-
Notifications
You must be signed in to change notification settings - Fork 67
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
Make using varients of protobuf easier. #17
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
/* | ||
* Copyright 2016-2019 Envoy Project Authors | ||
* Copyright 2020 Google LLC | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); | ||
* you may not use this file except in compliance with the License. | ||
* You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
|
||
/* | ||
* API Available to WASM modules. | ||
*/ | ||
// NOLINT(namespace-envoy) | ||
|
||
#pragma once | ||
#define PROXY_WASM_PROTOBUF_FULL 1 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is defined twice, once in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, yes I did. This is unfortunately AFAICT it is required because bazel doesn't seem to work the way one would reasonably expect it to work. The copts doesn't seem to be contagious to targets which depend on a a header from the library which defines the copt. Consequently in order to get the #define to actually impact the header when it is included in another target, ,e.g. gcpc_call_cpp.cc in test/extensions/filters/http/wasm/test_data, on needs to add it to that target or conversely one could use a header which includes it such as here. That said, my understanding of bazel is perhaps not what it should be and if you have a better solution I am all ears. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't want to add the copts in the wasm_cc_binary target because that is messy. This way I can conceal that mess in the proxy-wasm-cpp-sdk library proper. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You don't need copts in either place, just having this header should be enough. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Erm, I meant that you should remove define from There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then I have to add it at the higher level in the wasm_cc_binary targets which is messy and inconvenient. I can't include a different header in the proxy_wasm_intrinsics.cc file without having a #define so I need two targets for it with different copts. If you have a way to get this to work I would like to here it but I tried several ways and this was the best way I could find to get bazel to do what I want. I suppose I could build wasm_cc_binary_full and wasm_cc_binary_lite, but that doesn't seem to be an improvement either. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I still think that |
||
#include "proxy_wasm_intrinsics.h" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
/* | ||
* Copyright 2016-2019 Envoy Project Authors | ||
* Copyright 2020 Google LLC | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); | ||
* you may not use this file except in compliance with the License. | ||
* You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
|
||
/* | ||
* API Available to WASM modules. | ||
*/ | ||
// NOLINT(namespace-envoy) | ||
|
||
#pragma once | ||
#define PROXY_WASM_PROTOBUF_LITE 1 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (same here) |
||
#include "proxy_wasm_intrinsics.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about other gRPC functions? i.e.
open_stream
,send_message
,cancel
, andclose
? Shouldn't we be disabling them as well?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could. I was hoping to talk to others who might be interested in using say flatbuffers with gRPC. They might have alternative solutions for the functions which depend directly on MessageLite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd err on the of side having good support for features that we support, and not having support for features that we don't officially support, i.e. I'm 100% for adding back other functions iff someone adds support for gRPC with flatbuffers, but since we don't have it yet, I think we should disable reminding gRPC functions when compiled without protobuf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a bug preventing me from fixing this: envoyproxy/envoy-wasm#508
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gRPC doesn't have to be a protobuf payload, any buffer (string/string_view) should work and Envoy has support of that. But we should turn off those method with protobuf in its signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I turned the protobuf ones off, but I didn't provide the "string/string_vew" alternative. WDYT @PiotrSikora ? Should I add those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably add those (always, not only when building without protobuf), but it's fine to do that in a follow-up PR.