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 dependencies of the :parser target chain through antlr4's code generation and create a dependency on java runtime for the client. This could be eliminated by checking in generated code.
I realize checking in generated code is generally frowned upon, but I think creating a dependency chain that leads to requiring a completely different language runtime be installed by a library's client is also generally frowned upon. bison and yaccs generated code are frequently checked in rather than generated on-demand for this reason, so I think it would be reasonable to at least consider treating antlr4 generated code the same way.
My recommendation (if this was my project) would be to check in the generated code and have a golden file test which performs the antlr4 generation and compares the generated code to the checked in code - this provides the same assurances and version-reliability as having code generated on-demand, but moves the dependency chain to test-only which means it no longer cascades to clients of the library.
Including because it's useful for anyone else who has a problem with the java dependency, the change to make this happen is adding the generated files from bazel build //parser/internal:cel_grammer into parser/internal, and
diff --git a/parser/internal/BUILD b/parser/internal/BUILD
index 5b842c21..a808a339 100644
--- a/parser/internal/BUILD
+++ b/parser/internal/BUILD
@@ -12,8 +12,6 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-load("//bazel:antlr.bzl", "antlr_cc_library")
-
package(default_visibility = ["//visibility:public"])
licenses(["notice"])
@@ -23,8 +21,10 @@ cc_library(
hdrs = ["options.h"],
)
-antlr_cc_library(
- name = "cel",
- src = "Cel.g4",
- package = "cel_parser_internal",
+cc_library(
+ name = "cel_cc_parser",
+ srcs = ["CelLexer.cpp", "CelParser.cpp", "CelBaseVisitor.cpp", "CelVisitor.cpp"],
+ hdrs = ["CelLexer.h", "CelParser.h", "CelBaseVisitor.h", "CelVisitor.h"],
+ deps = ["@antlr4_runtimes//:cpp"],
+ linkstatic = 1,
)
The text was updated successfully, but these errors were encountered:
The dependencies of the
:parser
target chain through antlr4's code generation and create a dependency on java runtime for the client. This could be eliminated by checking in generated code.I realize checking in generated code is generally frowned upon, but I think creating a dependency chain that leads to requiring a completely different language runtime be installed by a library's client is also generally frowned upon. bison and yaccs generated code are frequently checked in rather than generated on-demand for this reason, so I think it would be reasonable to at least consider treating antlr4 generated code the same way.
My recommendation (if this was my project) would be to check in the generated code and have a golden file test which performs the antlr4 generation and compares the generated code to the checked in code - this provides the same assurances and version-reliability as having code generated on-demand, but moves the dependency chain to test-only which means it no longer cascades to clients of the library.
Including because it's useful for anyone else who has a problem with the java dependency, the change to make this happen is adding the generated files from
bazel build //parser/internal:cel_grammer
intoparser/internal
, andThe text was updated successfully, but these errors were encountered: