Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

incompatible_load_cc_rules_from_bzl: load cc rules from @rules_cc #8743

Closed
oquenchil opened this issue Jun 28, 2019 · 8 comments
Closed

incompatible_load_cc_rules_from_bzl: load cc rules from @rules_cc #8743

oquenchil opened this issue Jun 28, 2019 · 8 comments
Assignees
Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required) team-Rules-CPP Issues for C++ rules

Comments

@oquenchil
Copy link
Contributor

oquenchil commented Jun 28, 2019

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.

@oquenchil oquenchil added P1 I'll work on this now. (Assignee required) team-Rules-CPP Issues for C++ rules incompatible-change Incompatible/breaking change bazel 1.0 labels Jun 28, 2019
@oquenchil oquenchil self-assigned this Jun 28, 2019
bazel-io pushed a commit that referenced this issue Jul 22, 2019
The flag `--incompatible_load_cc_rules_from_bzl` will be flipped for Bazel 1.0.

GitHub Issue: #8743

RELNOTES:none
PiperOrigin-RevId: 259285337
@dslomov
Copy link
Contributor

dslomov commented Aug 5, 2019

Is the migration tooling available to do the migration?

@oquenchil
Copy link
Contributor Author

Went in at bazelbuild/buildtools@3a4128e

@dslomov
Copy link
Contributor

dslomov commented Aug 5, 2019

Went in at bazelbuild/buildtools@3a4128e

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

@oquenchil
Copy link
Contributor Author

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

Yannic added a commit to Yannic/googletest that referenced this issue Aug 7, 2019
Fixes googletest for upcoming `--incompatible_load_cc_rules_from_bzl` (bazelbuild/bazel#8743) and `--incompatible_load_python_rules_from_bzl` (bazelbuild/bazel#9006).

This change was automatically generated with
buildifier -lint=fix -warnings=all $(find . -name "BUILD" -o -name "BUILD.bazel" -o -name "*.bzl")
Yannic added a commit to Yannic/googletest that referenced this issue Aug 7, 2019
Fixes googletest for upcoming `--incompatible_load_cc_rules_from_bzl` (bazelbuild/bazel#8743) and `--incompatible_load_python_rules_from_bzl` (bazelbuild/bazel#9006).

This change was automatically generated with `buildifier -lint=fix -warnings=all $(find . -name "BUILD" -o -name "BUILD.bazel" -o -name "*.bzl")`.
@onet-git
Copy link

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
Copy link

onet-git commented Dec 3, 2019

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
Copy link
Contributor Author

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.

deepaksirone pushed a commit to multifacet/kalium that referenced this issue Dec 26, 2019
See bazelbuild/bazel#8743. This will be required in
Bazel 1.0.

Protobuf was updated in
protocolbuffers/protobuf@bf0c69e#diff-96239ee297e0a92ac6ff96a6bc434ef0.

GoogleTest was updated in
google/googletest@6fd262e.

gflags has not yet been updated, so the repo still won't build with
--incompatible_load_cc_rules_from_bzl.

Tested with buildifier -warnings=native-cc -lint=warn **/BUILD.

PiperOrigin-RevId: 267638515
agl added a commit to google/boringssl that referenced this issue Feb 6, 2020
Starting with Bazel 3.0, C++ rules will require loads. See
bazelbuild/bazel#8743

Thanks to Yannic Bonenberger for noting this in
https://boringssl-review.googlesource.com/c/boringssl/+/39825

Change-Id: I8e274c82ade6c7ec569989026190f6a0a88b47ed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39924
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
@lberki
Copy link
Contributor

lberki commented Oct 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required) team-Rules-CPP Issues for C++ rules
Projects
None yet
Development

No branches or pull requests

9 participants