You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.0does 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
The text was updated successfully, but these errors were encountered:
Description of the bug:
When upgrading from Bazel
6.5.0
to Bazel7.5.0
, I found a potential undesired inconsistency behavior ofcc_library
'sstrip_include_prefix
attribute.I'm using
WORKSPACE
(i.e. BzlMod is disabled).The inconsistency causes behavior change when switching Bazel versions (
6.5.0
and7.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 Bazel7.5.0
does not add-I
to some virtual includes directory when usingstrip_include_prefix = "."
on acc_library
target in an external repository.However, Bazel
7.5.0
processes correctlystrip_include_prefix = "."
on a local target;strip_include_prefix = "segment"
on both local or remote targets;include_prefix = "."
on a remote target;There are a number of opensource external repositories using
strip_include_prefix = "."
in theirBUILD
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 Bazel7.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
'sdeps
and runbazel build --enable_bzlmod=0 //src:main
, check#warning
printed to identify actual inclusions (i.e. headers visible). Compare between7.5.0
and6.5.0
to see the difference.BTW: We'd prefer
strip_include_prefix
overincludes
because the latter may expose unwanted (e.g. private) headers to dependents, insrc/BUILD
in the demo repository you can see the differences thatxxx.inc.h
got included whenincludes = ["."]
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
returnsdevelopment 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
?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 as7.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
The text was updated successfully, but these errors were encountered: