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

feat(cc toolchain): support external_include_paths on macos #21949

Conversation

jungleraptor
Copy link
Contributor

@jungleraptor jungleraptor commented Apr 9, 2024

The external_include_paths feature enables specifying include paths locally with -I and with -isystem when the project is included as an external repo.

This makes it possible to set -Werror against your own headers for development without propagating this to consumers of your libraries.

For some reason this was only previously enabled on linux. I do not see a reason for not also enabling it on macos.

The external_include_paths feature on mac enables specifying
include paths locally with -I and with -isystem when the project
is included as an external repo.

This makes it possible to set -Werror against your own headers
for development without propagating this to consumers of your libraries.

For some reason this was only previously enabled on linux.
@github-actions github-actions bot added team-Rules-CPP Issues for C++ rules awaiting-review PR is awaiting review from an assigned reviewer labels Apr 9, 2024
@fmeum
Copy link
Collaborator

fmeum commented Apr 26, 2024

Cc @keith

@keith
Copy link
Member

keith commented Apr 26, 2024

interesting. this doesn't exist in the apple_support toolchain today either. what ends up propagating things as external headers?

@jungleraptor
Copy link
Contributor Author

interesting. this doesn't exist in the apple_support toolchain today either. what ends up propagating things as external headers?

It works with strip_include_prefix and friends.

So you use that^ to specify include paths and locally they get compiled with -I and - when that feature is enabled in a consuming repo - they get compiled with -isystem.

Using the includes attribute only sets -isystem by default which ignores whatever compiler/linter warnings you've set up.

@keith
Copy link
Member

keith commented May 6, 2024

also added this here: bazelbuild/apple_support#327

@comius comius added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels May 15, 2024
@github-actions github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label May 16, 2024
@brentleyjones
Copy link
Contributor

@bazel-io flag

@bazel-io bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label May 16, 2024
@keertk
Copy link
Member

keertk commented May 16, 2024

@bazel-io fork 7.2.0

@bazel-io bazel-io removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label May 16, 2024
bazel-io pushed a commit to bazel-io/bazel that referenced this pull request May 16, 2024
The external_include_paths feature enables specifying include paths locally with -I and with -isystem when the project is included as an external repo.

This makes it possible to set -Werror against your own headers for development without propagating this to consumers of your libraries.

For some reason this was only previously enabled on linux. I do not see a reason for not also enabling it on macos.

Closes bazelbuild#21949.

PiperOrigin-RevId: 634394452
Change-Id: I0df91b2a2c9b4a5bd52b22e64f99ea0745cb9759
github-merge-queue bot pushed a commit that referenced this pull request May 17, 2024
…22413)

The external_include_paths feature enables specifying include paths
locally with -I and with -isystem when the project is included as an
external repo.

This makes it possible to set -Werror against your own headers for
development without propagating this to consumers of your libraries.

For some reason this was only previously enabled on linux. I do not see
a reason for not also enabling it on macos.

Closes #21949.

PiperOrigin-RevId: 634394452
Change-Id: I0df91b2a2c9b4a5bd52b22e64f99ea0745cb9759

Commit
d831214

Co-authored-by: Isaac Torres <isaac@isaactorz.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-Rules-CPP Issues for C++ rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants