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
# Note: We need to apply commands to headers and sources.
# Why? clangd currently tries to infer commands for headers using files with similar paths. This often works really poorly for header-only libraries. The commands should instead have been inferred from the source files using those libraries... See https://github.com/clangd/clangd/issues/123 for more.
# When that issue is resolved, we can stop looking for headers and just return the single source file.
It sounds like there might be some poor devx cases being solved here, but it's not entirely clear to me if it's something we will be affected by or not. Do you remember some more specifics I could test on our project to determine if this time is worth spending? For reference >75% of the generating time is eliminated if we don't generate commands for headers, which is pretty tempting for us. Also we're migrating from cmake and the cmake generated file doesn't include headers either, so I'm definitely interested in the bazel specifics that cause this.
The text was updated successfully, but these errors were encountered:
# Using ccls or another tool that doesn't want or need headers in compile_commands.json?
# exclude_headers = "all", # By default, we include entries for headers to support clangd, working around https://github.com/clangd/clangd/issues/123
# ^ excluding headers will speed up compile_commands.json generation *considerably* because we won't need to preprocess your code to figure out which headers you use.
# However, if you use clangd and are looking for speed, we strongly recommend you follow the instructions below instead, since clangd is going to regularly infer the wrong commands for headers and give you lots of annoyingly unnecessary red squigglies.
While debugging the perf of this tool in our project I discovered this:
bazel-compile-commands-extractor/refresh.template.py
Lines 665 to 667 in 1e08f8e
It sounds like there might be some poor devx cases being solved here, but it's not entirely clear to me if it's something we will be affected by or not. Do you remember some more specifics I could test on our project to determine if this time is worth spending? For reference >75% of the generating time is eliminated if we don't generate commands for headers, which is pretty tempting for us. Also we're migrating from cmake and the cmake generated file doesn't include headers either, so I'm definitely interested in the bazel specifics that cause this.
The text was updated successfully, but these errors were encountered: