trouble migrating gRPC to bazel 1.0.0: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type

[Jan Tattermusch]

Hey,

I'm trying to migrate grpc to just released bazel 1.0, but I'm having trouble with getting the local build working. Bazel RBE build works just fine.

When I try building locally (bazel build //test/...), I'm getting this error:

ERROR: While resolving toolchains for target //test/cpp/qps:qps_openloop_test: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type ERROR: Analysis of target '//test/cpp/qps:qps_openloop_test' failed; build aborted: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type INFO: Elapsed time: 26.889s INFO: 0 processes. FAILED: Build did NOT complete successfully (107 packages loaded, 5895 targets configured)

This is the pull request

https://github.com/grpc/grpc/pull/20558

--

Jan

[Jakob Buchgraber]

Heya Jan,

the reason for this error is the use of exec_compatible_with on the qps_openloop_test target. The default cpp toolchain

does not know about the //third_party/toolchains/machine_size:large constraint. Using execution constraints for machine

types has always been a hack and Bazel 1.0 has a better way to do it.

Instead of

grpc_cc_test(

  ...

  exec_compatible_with = ["//third_party/toolchains/machine_size:large"],

)

use

grcp_cc_test(

  ...

  exec_properties = { "gceMachineType" : "n1-standard-8"},

)

Unlike exec_compatible_with the new exec_properties attribute does not affect toolchain resolution. Instead it just passes the key

value pairs through to the remote execution system.

Instead of hardcoding the values I recommend defining some constant in a central place.

third_party/toolchains/defs.bzl:

LARGE_MACHINE = { "gceMachineType" : "n1-standard-8"}

test/cpp/qps/BUILD:

load("//third_party/toolchains/defs.bzl", "LARGE_MACHINE")

grpc_cc_test(

  ...,

  exec_properties = LARGE_MACHINE,

)

+Eytan Kidron is working on having these Starlark constructs in a central place in https://github.com/bazelbuild/bazel-toolchains but

afaik it has not shipped yet.

Best,

Jakob

Jakob Buchgraber

Software Engineer

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CACF4M0RHiXmF%3DEt-0rYT0hWc56C4SrXpwO%2Benj81%3DTs35NRsgw%40mail.gmail.com.

[Alexandra Goultiaeva]

Have you tried the "bazelisk --migrate"?

I suspect you're being broken by --incompatible_auto_configure_host_platform

TL;DR: if you're referring to @bazel_tools//platforms:host_platform anywhere in your configuration, replace it with @local_config_platform//:host

[Gunnar Wagenknecht]

Hi Jakob,

I have the same error running Bazel build inside CentOS Docker container. It works fine on my local Mac. The build is a pretty straightforward Java build using rules_jvm_external. Not sure why it would require a cpp toolchain.

FWIW, a simple cc_library test build works fine in the container. Any ideas what I can try to debug it?

-Gunnart

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-...@googlegroups.com.