#2328: Use Starlark rules

[axman6]

An attempt to fix #2328, which removes the use of the native rules_cc, rules_java and protobuf rules. bazel build [--enable_bzlmod] //... and bazel build [--enable_bzlmod] //... all build and pass on my machine so hopefully this has actually worked...

Updates deps:

• rules_cc: 0.0.9 -> 0.0.17 (latest 0.0.X version)
• rules_java: 6.1.0 -> 6.5.2 (latest 6.X.Y version)
• protobuf: 21.7 -> 28.3 (matching haskell/repositories.bzl)

Each commit should probably be reviewed separately, most changes were from buildifier, with the final commit implementing some optional changes suggested by the LSP including documenting some undocumented arguments as far as I could understand them.

[axman6]

Looks like this is broken in CI, and I don't have a clue where to begin to fix it. I'll take another look on Monday.

[avdv]

Thank you, that looks quite good.

It just seems there is a problem with running the example and the start script regarding rules_java.

This is because you only added rules_java to the WORKSPACE file for rules_haskell, which only has an effect on this project (all tests are green for rules_haskell) but does not have any effect on other workspaces (such as the example or in the project created by the start script).

You should add a similar maybe(http_archive, ...) call for rules_java to haskell/repositories.bzl like the one for rules_cc (an exception to this are dev dependencies that are only used during development). Any setup calls (like rules_java_dependencies) need to be added to every WORKSPACE file separately, including the start script which generates a WORKSPACE file.

BTW, usually we try to be quite conservative with module updates in MODULE.bazel files for the main module and only bump bazel_deps in the test module. Due to the MVS algorithm we ensure that things work for newer versions but don't force anyone else using rules_haskell to use the latest version of our dependencies. This is in contrast to WORKSPACE mode where one is free to use a different version whatsoever. See https://github.com/tweag/renovate-presets#why-are-updates-to-the-root-modulebazel-ignored for the rationale.

Having said that, if things work with the current version bumps, let's keep them this way as Bazel 6 is EOL already and we really ought to move on to Bazel 7 and 8...

One thing that failed after the version bump of protobuf is the Windows compilation, see https://github.com/tweag/rules_haskell/actions/runs/26277294428/job/77344953463?pr=2429 -- so that should probably be reverted.