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

Support source_filter_packages #97

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion refresh.template.py
Original file line number Diff line number Diff line change
Expand Up @@ -861,7 +861,7 @@ def _get_commands(target: str, flags: str):
# Aquery docs if you need em: https://docs.bazel.build/versions/master/aquery.html
# Aquery output proto reference: https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/analysis_v2.proto
# One bummer, not described in the docs, is that aquery filters over *all* actions for a given target, rather than just those that would be run by a build to produce a given output. This mostly isn't a problem, but can sometimes surface extra, unnecessary, misconfigured actions. Chris has emailed the authors to discuss and filed an issue so anyone reading this could track it: https://github.com/bazelbuild/bazel/issues/14156.
f"mnemonic('(Objc|Cpp)Compile',deps({target}))",
f"mnemonic('(Objc|Cpp)Compile', filter('({source_filter_packages})', deps({target})))",
# We switched to jsonproto instead of proto because of https://github.com/bazelbuild/bazel/issues/13404. We could change back when fixed--reverting most of the commit that added this line and tweaking the build file to depend on the target in that issue. That said, it's kinda nice to be free of the dependency, unless (OPTIMNOTE) jsonproto becomes a performance bottleneck compated to binary protos.
'--output=jsonproto',
# We'll disable artifact output for efficiency, since it's large and we don't use them. Small win timewise, but dramatically less json output from aquery.
Expand Down
10 changes: 9 additions & 1 deletion refresh_compile_commands.bzl
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,11 @@ refresh_compile_commands(
# If you don't care about browsing headers from external workspaces or system headers, except for a CTRL/CMD+click every now and then:
# Then no need to add entries for their headers, because clangd will correctly infer from the CTRL/CMD+click (but not a quick open or reopen).
# exclude_headers = "external",
# If you want to just extract the package you care about.
# Then set names of package to source_filter_packages
# The following name are supported
# ['@third//', '@third', '@third//foo', '@third//foo:bar', '@third//...']
# ['//...', '//foo', 'foo', '//foo:bar', '//foo:...']
# Still not fast enough?
# Make sure you're specifying just the targets you care about by setting `targets`, above.
```
Expand All @@ -63,6 +68,7 @@ def refresh_compile_commands(
targets = None,
exclude_headers = None,
exclude_external_sources = False,
source_filter_packages = [],
**kwargs): # For the other common attributes. Tags, compatible_with, etc. https://docs.bazel.build/versions/main/be/common-definitions.html#common-attributes.
# Convert the various, acceptable target shorthands into the dictionary format
# In Python, `type(x) == y` is an antipattern, but [Starlark doesn't support inheritance](https://bazel.build/rules/language), so `isinstance` doesn't exist, and this is the correct way to switch on type.
Expand All @@ -79,7 +85,7 @@ def refresh_compile_commands(

# Generate runnable python script from template
script_name = name + ".py"
_expand_template(name = script_name, labels_to_flags = targets, exclude_headers = exclude_headers, exclude_external_sources = exclude_external_sources, **kwargs)
_expand_template(name = script_name, labels_to_flags = targets, exclude_headers = exclude_headers, exclude_external_sources = exclude_external_sources, source_filter_packages = source_filter_packages, **kwargs)
native.py_binary(name = name, srcs = [script_name], **kwargs)

def _expand_template_impl(ctx):
Expand All @@ -95,6 +101,7 @@ def _expand_template_impl(ctx):
" {windows_default_include_paths}": "\n".join([" %r," % path for path in find_cpp_toolchain(ctx).built_in_include_directories]), # find_cpp_toolchain is from https://docs.bazel.build/versions/main/integrating-with-rules-cc.html
"{exclude_headers}": '"' + str(ctx.attr.exclude_headers) + '"',
"{exclude_external_sources}": str(ctx.attr.exclude_external_sources),
"{source_filter_packages}": "|".join(ctx.attr.source_filter_packages),
},
)
return DefaultInfo(files = depset([script]))
Expand All @@ -104,6 +111,7 @@ _expand_template = rule(
"labels_to_flags": attr.string_dict(mandatory = True), # string keys instead of label_keyed because Bazel doesn't support parsing wildcard target patterns (..., *, :all) in BUILD attributes.
"exclude_external_sources": attr.bool(default = False),
"exclude_headers": attr.string(values = ["all", "external", ""]), # "" needed only for compatibility with Bazel < 3.6.0
"source_filter_packages": attr.string_list(),
"_script_template": attr.label(allow_single_file = True, default = "refresh.template.py"),
"_cc_toolchain": attr.label(default = "@bazel_tools//tools/cpp:current_cc_toolchain"), # For Windows INCLUDE. If this were eliminated, for example by the resolution of https://github.com/clangd/clangd/issues/123, we'd be able to just use a macro and skylib's expand_template rule: https://github.com/bazelbuild/bazel-skylib/pull/330
},
Expand Down