Skip to content
New issue

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

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

Already on GitHub? # to your account

Inconsistent behavior on cc_library.strip_include_prefix of Bazel 7+ #25339

Open
wudisheng opened this issue Feb 20, 2025 · 0 comments
Open

Inconsistent behavior on cc_library.strip_include_prefix of Bazel 7+ #25339

wudisheng opened this issue Feb 20, 2025 · 0 comments
Labels

Comments

@wudisheng
Copy link

wudisheng commented Feb 20, 2025

Description of the bug:

When upgrading from Bazel 6.5.0 to Bazel 7.5.0, I found a potential undesired inconsistency behavior of cc_library's strip_include_prefix attribute.

I'm using WORKSPACE (i.e. BzlMod is disabled).

The inconsistency causes behavior change when switching Bazel versions (6.5.0 and 7.5.0), and when working on the same code through local targets and remote targets in external repository.

To better demonstrate and describe the inconsistency, I have summarize a demo repository (inconsistency.tar.gz), and I have recorded the bahavior in src/BUILD.

From my point of view, Bazel 6.5.0 works as expected, while Bazel 7.5.0 does not add -I to some virtual includes directory when using strip_include_prefix = "." on a cc_library target in an external repository.

However, Bazel 7.5.0 processes correctly

  • when using strip_include_prefix = "." on a local target;
  • when using strip_include_prefix = "segment" on both local or remote targets;
  • when using include_prefix = "." on a remote target;

There are a number of opensource external repositories using strip_include_prefix = "." in their BUILD files, so the migration would be not easy. I wonder what's the original intention of the behavior change (or is it intentional from the beginning?), and if there is a way to configure Bazel 7.5.0 so that the breakage can be mitigated.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Unpack inconsistency.tar.gz from the attachment, then uncomment one entry per time in //src:main's deps and run bazel build --enable_bzlmod=0 //src:main, check #warning printed to identify actual inclusions (i.e. headers visible). Compare between 7.5.0 and 6.5.0 to see the difference.

BTW: We'd prefer strip_include_prefix over includes because the latter may expose unwanted (e.g. private) headers to dependents, in src/BUILD in the demo repository you can see the differences that xxx.inc.h got included when includes = ["."] is used.

Which operating system are you running Bazel on?

Ubuntu 22.04

What is the output of bazel info release?

7.5.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

N/A

What's the output of git remote get-url origin; git rev-parse HEAD ?

N/A

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Bazel 7.0.0 has the same bahavior as 7.5.0, so it seems an undocumented incompatible behavior change of major release (7.x).

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants