You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proto/ gradle targets generate protos for all languages (java, python, go and C++), but in the C++ case, the generated files are not used, but generated with a different script and checked in under cpp-client/deephaven/proto. Before #6073, a task was run to check the output of both was at least consistent; after 6073 and for reasons explained in that ticket, the task is disabled.
We need to decide and execute on a way to cleanup this duplicity and/or inconsistency. Alternatives are:
a. Once the protobuf fandango cleans up we can go back to the state before 6073 and re-enable the consistency check.
b. We can stop generating C++ for the proto/ gradle targets, and let C++ do its thing. I personally tend to favor this option, as I think it would be more flexible and no more risky (since we have tests and protbuf binary format is very stable) for each language to be able to do its own thing in terms of protobuf versions.
c. (orthogonal with the two above) we should consider removing the need to check in proto generated code in the C++ client, and just depend on its generation, like we do in other languages.
Assigning to colin from our agreement in the discussion for 6073.
The text was updated successfully, but these errors were encountered:
The
proto/
gradle targets generate protos for all languages (java, python, go and C++), but in the C++ case, the generated files are not used, but generated with a different script and checked in undercpp-client/deephaven/proto
. Before #6073, a task was run to check the output of both was at least consistent; after 6073 and for reasons explained in that ticket, the task is disabled.We need to decide and execute on a way to cleanup this duplicity and/or inconsistency. Alternatives are:
a. Once the protobuf fandango cleans up we can go back to the state before 6073 and re-enable the consistency check.
b. We can stop generating C++ for the
proto/
gradle targets, and let C++ do its thing. I personally tend to favor this option, as I think it would be more flexible and no more risky (since we have tests and protbuf binary format is very stable) for each language to be able to do its own thing in terms of protobuf versions.c. (orthogonal with the two above) we should consider removing the need to check in proto generated code in the C++ client, and just depend on its generation, like we do in other languages.
Assigning to colin from our agreement in the discussion for 6073.
The text was updated successfully, but these errors were encountered: