[email protected]

[kgreenek]

Closes #3487

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (lanelet2) have been updated in this PR. Please review the changes.

[wep21]

needs presubmit.yml?

[kgreenek]

needs presubmit.yml?

Doh I was in too much of a rush this morning! Added

[kgreenek]

@bazel-io skip_check unstable_url

[kgreenek]

PTAL

Sorry for the noise

[wep21]

@fmeum @meteorcloudy please add presubmit auto run

[fmeum]

Checks are falling

[wep21]

please update geographiclib after #3495 is merged.

[kgreenek]

The test errors are tough to debug because I can't reproduce here locally. On my machine and my CI the tests pass.

Is it possible for me to see the .bazelrc that is being used in these CI checks?

Require module maintainers' approval for newly pushed changes.

[kgreenek]

Nevermind! I figured it out. I needed to pass the c++17 args in my presubmit.yml

[kgreenek]

This is just waiting until the geographiclib fix is merged to main now

[kgreenek]

@fmeum I could use your help.

I think the current CI failure with bazel rolling in this PR can only be fixed once rules_cc v0.1.1 is released.

The reason is because boost require the rules_cc version to be 0.1.0. And since 0.1.0 is higher than 0.0.17 I can't specify a version besides 0.1.0 here. However, 0.1.0 does not contain the runfiles definitions in rules_cc that would be needed to break the cycle that causes the build to fail.

It looks like bazel tools in rolling now depends on rules_cc. But rules_cc 0.1.0 depends on bazel tools.
See:
https://github.com/bazelbuild/rules_cc/blob/0.1.0/cc/runfiles/BUILD#L5

Hence, I think I either need to wait for rules_cc 0.1.1, or I would need to somehow get rules_cc 0.0.17, which has the newer rules_cc runfiles macro which does not depend on bazel tools.

Here's the error:

(07:08:19) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/6ba68aacb32a9a3eb373d5b292e7e579/external/bazel_tools/tools/cpp/runfiles/BUILD:1:11: in cc_library rule @@bazel_tools//tools/cpp/runfiles:runfiles: cycle in dependency graph:
    @@lanelet2+//:lanelet2_io_test (b777599e4daec69c84b8dea9290f68043118d9d1328876eb1515a5c541e8a806)
    @@bazel_tools//tools/cpp/runfiles:runfiles (b777599e4daec69c84b8dea9290f68043118d9d1328876eb1515a5c541e8a806)
.-> @@bazel_tools//tools/cpp/runfiles:runfiles (7f0665c24598269e6100c4a15535c8239f48b5033f2be3be41783159023fadc4)
|   @@rules_cc+//cc/runfiles:runfiles (7f0665c24598269e6100c4a15535c8239f48b5033f2be3be41783159023fadc4)
`-- @@bazel_tools//tools/cpp/runfiles:runfiles (7f0665c24598269e6100c4a15535c8239f48b5033f2be3be41783159023fadc4)

Do you have any suggestions for the best way I can resolve this?

[fmeum]

Could boost downgrade to a lower rules_cc version in a new version? Depending on the minimum required version rather than the latest version is recommended with Bzlmod.

At the same time it's totally fine for rolling to require unreleased ruleset versions. Keeping rolling in your BCR presubmit (rather than just your module's own CI) is somewhat risky in that regard.

Cc @comius for potential advice on the future of v0.1.* vs v0.0.* of rules_cc.

[kgreenek]

I think downgrading the version of rules_cc required by the boost libraries would be a good idea.

FWIW there are some other compatibility issues because rules_cc 0.1.0 removed cc_proto_library.

I found that I currently cannot depend on both boost and protobuf because a transitive dependency is not compatible with rules_cc 0.1.0.

I submitted a PR upstream to the offending package here (bufbuild/protoc-gen-validate#1210). If they merge that and create a release, then I can update the version in the BCR and make everything compatible with rules_cc 0.1.0.

I'll send up a PR shortly that illustrates the issue.