includes attribute in cc_import has different semantics than includes attribute in cc_library

[konste]

Description of the bug:

cc_library rule has includes attribute to specify the list of include dirs to be added to the compile line. In this case specified folders are interpreted as relative to the current package. cc_import rule (both in Java and in Starlark) also has the same includes attribute for the same purpose, but in this case specified folders are interpreted as relative to the root of the WORKSPACE! This must be a bug.

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

I prepared a tiny repro of the problem here. Build can be invoked with ./bazel.sh build executable

In shared_lib folder I defined two targets - shared_lib which builds and imported_lib which imports. They both have the same public header in hdrs attribute and as the header is in the same folder includes = ["."]

When executable depends on shared_lib it sees that public header as expected, but if we make it depend on the imported_lib instead the build fails because the compiler does not see that header in specified includes folders. To make it work we can change includes attribute to [package_name()]

Which operating system are you running Bazel on?

Linux, Windows

What is the output of bazel info release?

6.2.0

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

No response

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

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

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

No response

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[visglz]

The issue is still present. I can reproduce the problem with Bazel 7.4.1 under Linux.

The include directory is not prepended with the package path leading to an incorrect build and finally to a build break.

I set up a small project for reproduction.

This issue is also related to #19182

[visglz]

The issue is still present with Bazel 8.0.1. I adapted the reproduction repo.

[keith]

I believe fixed by https://github.com/bazelbuild/bazel/pull/25709