incompatible_load_cc_rules_from_bzl: load cc rules from @rules_cc

[oquenchil]

Flag: --incompatible_load_cc_rules_from_bzl
Available since: 0.28 (July2019 release)
Will be flipped in: 1.0 (September 2019 release)
Tracking issue: #7643

cc_library, cc_binary, cc_test, cc_import, cc_proto_library, fdo_profile, fdo_prefetch_hints, objc_library, objc_import, cc_toolchain, cc_toolchain_suite, cc_flags_supplier and compiler_flag have to be loaded from @rules_cc.

For example if you are using cc_library, add the following load statement to your BUILD/bzl file.
load("@rules_cc//cc:defs.bzl", "cc_library")

You will have to add the rules_cc to your WORKSPACE file as well:

http_archive(
    name = "rules_cc",
    sha256 = "e75dfb05bc1e89ebbb6696cadb5e455833690009310d9dc5512151c5adb0e4e3",
    strip_prefix = "rules_cc-cfe68f6bc79dea602f2f6a767797f94a5904997f",
    urls = [         
  "https://github.com/bazelbuild/rules_cc/archive/cfe68f6bc79dea602f2f6a767797f94a5904997f.zip",
    ],
)

There is a bug in a previous version of rules_cc that may cause problems when you have tags of your own that come from a separate bzl file. If you have to use the old version of rules_cc, you can get around the bug by passing tags = list(TAGS) to the cc_* rule. instead of doing tags = TAGS directly.

[dslomov]

Is the migration tooling available to do the migration?

[oquenchil]

Went in at bazelbuild/buildtools@3a4128e

[dslomov]

Went in at bazelbuild/buildtools@3a4128e

Nice! But this tooling does not update WORKSPACE file, right?

[oquenchil]

Nope, but rules_cc is in the WORKSPACE suffix. This was needed by Java, so it's always present.

[onet-git]

This migration is currently blocked by bazelbuild/rules_cc#39. In a codebase heavily dependant on tags, running buildifier -lint=fix breaks everything.

[onet-git]

The the automatic updating of BUILD files with the lack of rules_* versions is breaking builds. There have been no github releases of rules_* projects so WORKSPACES are based on information found in bugs like this or the grpc code, versions with known issues.

Bazel 1.2.0 is warning about not loading rules_* so people are running buildifier, which is then breaking their builds. Since bazel is issuing these warning it should also include default rules_* versions that are believed to work with that version of bazel. Being able to override that setting would be nice, but there needs to at least be a reasonable default.

[oquenchil]

Which rules_* is breaking exactly? Is it breaking for cc?

We have the rules_cc repository in the suffix, so it should not be a problem unless you bump into the tags issue in bazelbuild/rules_cc#39. If that happens you will have to manually update the WORKSPACE to include the latest rules_cc version.

[lberki]

Update: We decided not to require everyone to add a load() statement to every single BUILD file because it's too much churn. The current plan is to "pretend" that the eventual C++/Java rules written in Starlark are load()ed everywhere.

We might revisit this decision once they are reasonably stable and once we decide where exactly they need to be load()ed from, but now is not the time.