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
This change adds two main features:
1. You can configure compile commands for certain targets to go into
separate files
For embedded systems development in particular, `clangd` doesn't work
well with `compile_commands.json` generated for multiple targets. For
example, if you have a build target that runs on your host machine in
one configuration and another that runs on device in another
configuration, `compile_commands.json` will contain multiple conflicting
compile commands for the same source files. `clangd` will just use the
first one it finds, which may not be the one you want to use for code
intelligence. It's convenient to have separate compile commands files
for each target, and switch the file `clangd` uses depending on how you
want to navigate your code.
By providing the `target_file_names` argument, you can associate targets
with names. Separate compile commands files will be generated for each
of the specified targets, and will be placed in subdirectories with the
specified names. Compile commands for any targets that aren't specified
in `target_file_names` will go into the main compile commands file, just
like before.
2. You can specify a different output path
If you are generating multiple compile commands files, its preferable
not to output them into the workspace root. So you can specify a
separate output path, relative to the workspace root.
This patch doesn't change any existing behavior; if you don't add either
of the new arguments to your invocation of `refresh_compile_commands`,
everything will work exactly as it did before.
Copy file name to clipboardExpand all lines: refresh_compile_commands.bzl
+28-3Lines changed: 28 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -36,6 +36,15 @@ refresh_compile_commands(
36
36
# ^ 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.
37
37
# 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.
38
38
39
+
# Need to create separate files for specific targets? Give those targets a name and their compile commands file will be written into a subdirectory with that name.
40
+
# target_file_names = {
41
+
# "//:host_build": "host",
42
+
# "//:target_build": "target",
43
+
# }
44
+
45
+
# Need to write compile commands to some directory other than the workspace root? Provide a path relative to the workspace root.
46
+
# out_dir = ".compile_commands"
47
+
39
48
# Need things to run faster? [Either for compile_commands.json generation or clangd indexing.]
40
49
# First: You might be able to refresh compile_commands.json slightly less often, making the current runtime okay.
41
50
# If you're adding files, clangd should make pretty decent guesses at completions, using commands from nearby files. And if you're deleting files, there's not a problem. So you may not need to rerun refresh.py on every change to BUILD files. Instead, maybe refresh becomes something you run every so often when you can spare the time, making the current runtime okay.
**kwargs): # For the other common attributes. Tags, compatible_with, etc. https://docs.bazel.build/versions/main/be/common-definitions.html#common-attributes.
@@ -78,9 +89,15 @@ def refresh_compile_commands(
78
89
eliftype(targets) !="dict": # Assume they've supplied a single string/label and wrap it
" {target_file_names}": "\n".join([" '{}': '{}',".format(target, file_name) for (target, file_name) inctx.attr.labels_to_file_names.items()]),
114
136
" {windows_default_include_paths}": "\n".join([" %r,"%pathforpathinfind_cpp_toolchain(ctx).built_in_include_directories]), # find_cpp_toolchain is from https://docs.bazel.build/versions/main/integrating-with-rules-cc.html
0 commit comments