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

bazel build does not mark includes as system headers #837

Open
joshuarubin opened this issue Jul 6, 2022 · 3 comments
Open

bazel build does not mark includes as system headers #837

joshuarubin opened this issue Jul 6, 2022 · 3 comments
Assignees

Comments

@joshuarubin
Copy link

By not using includes in the cc_library for the bazel build, includes are considered local. This poses a problem for tools like clang-tidy that can suppress issues coming from system headers. As a result, our lint output is littered with glog errors.

@drigz
Copy link
Member

drigz commented Jul 8, 2022

e6e2e13 replaced includes with strip_include_prefix. It's a "grab bag" commit, but I believe the relevant explanation is "No longer expose internal headers." Feel free to send a pull request to switch back, but please ensure that downstream targets that do eg #include <stacktrace.h> do not pick up the glog-internal header, since I think this is why the switch was made.

@sergiud
Copy link
Collaborator

sergiud commented Feb 22, 2023

Is this still an issue?

@drigz
Copy link
Member

drigz commented Feb 23, 2023

I guess so, I'm not aware of a way to avoid the "exposing the private config.h header" without having the effect that the reporter described, although presumably it could be done by rearranging/renaming the source/include files in this repo and adjusting the CMake build accordingly.

drigz added a commit that referenced this issue May 31, 2023
#837 has caused a couple of
disappointments for PR authors, so I'm hoping this comment can save them
some time, or even help them towards finding a complete solution for the
problem.
drigz added a commit that referenced this issue Jun 5, 2023
#837 has caused a couple of
disappointments for PR authors, so I'm hoping this comment can save them
some time, or even help them towards finding a complete solution for the
problem.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants