I have a .bzl file in the same directory as WORKSPACE. This .bzl file is loaded by the WORKSPACE and one other file in the source tree.
bazel query --universe_scope=//... --order_output=no 'rbuildfiles(variables.bzl)'
prints the paths of the two files I would expect, but also references to about 200 other files which are all external dependencies and cannot possibly depend on variables.bzl
for example:
#pypi__futures_3_2_0//:BUILD
#pypi__grpcio_1_14_1//:BUILD
#eigen//:BUILD.bazel
#io_bazel_rules_go//go/private:BUILD.bazel
Assuming I am doing something incorrectly and that this is not a bug. Any expertise would be greatly appreciated. How can I use rbuilddeps to return /only/ the files which load variables.bzl?
The WORKSPACE file of the main repo can arbitrarily affect external repositories. So, rbuildfiles is showing you because changes to variables.bzl could in fact affect all those external BUILD files indirectly through WORKSPACE.
If you don't actually want to see the BUILD files in external repositories, you could intersect the result of rbuildfiles with //....
Related
I have have library with an artifact: src/lib/prelude.kind that I'd like to access. However, when I call the library code from a different project (which has the library set up as a dependency), the file src/lib/prelude.kind doesn't exist.
I can solve this problem by hardcoding the file location as _build/default/lib/kind/src/prelude.kind instead, but I'd rather not hardcode the Rebar3 default profile path.
Is there a way to refer to _build/default/lib or whatever the current profile location is from Erlang in a Rebar3 project?
You should use code:lib_dir/2
I'd make sure that the file is available with rebar3's artifacts (and move it out of the src subdir)
I have a Bazel project with a WORKSPACE and many packages. WORKSPACE file is quite huge, so I wonder if it's possible to break it down in separated files and import them.
You can extract parts of the WORKSPACE into .bzl files, and load() these symbols for variables and functions into the WORKSPACE.
load("//foo/bar:file.bzl", "function_for_workspace")
function_for_workspace()
See Loading an extension for more information.
I am aware that bazel accepts both BUILD and BUILD.bazel as valid filenames.
The android tools seem to also have a BUILD.tools file.
In general, does bazel have any restrictions for a BUILD file's extension? For example, could i have BUILD.generated to delineate generate BUILD files from non-generated BUILD files?
The .tools extension is part of building Bazel itself. From the perspective of Bazel, it's just any ordinary file. It gets picked up here: https://github.com/bazelbuild/bazel/blob/bbc8ed16aee07c3ba9321d58aa4c0ffc55fa2ba9/tools/android/BUILD#L197
then eventually gets processed here: https://github.com/bazelbuild/bazel/blob/c816b89a2224c3c318f1228755ef41c53975f45c/src/create_embedded_tools.py#L74
For the use case you mention, one way to go about it is to generate a .bzl file with a meaningful name that contains a macro that you can call from a BUILD or BUILD.bazel file. That way you can separate the generated rules from manually maintained rules. This is similar to how generate_workspace works: https://docs.bazel.build/versions/master/generate-workspace.html
I have studied https://blog.bazel.build/2017/02/27/protocol-buffers.html . The project I want to hack on is written in Go. At the moment, if I run the build command I can see the compiled binary but I don't see the *.pb.go files anywhere. I want to keep the generated *.pb.go files in the same folder where *.proto files are so that my IDE (Intellij Goland) can find and index them.
Can you please help me how to get this working? If you can show me how to do that for the github.com/cgrushko/proto_library project, I should be able to try that in my particular project.
Bazel will not output generated files (such as .pb.go) into the source tree. They go into the output directories (bazel-out/<config> or bazel-genfiles/<config>). Temporary solution might be to add those as source roots to goland. The real solution is to use https://ij.bazel.build/. It has some Go support, and the team is actively working on improving it.
I'm writing a post-build tool that needs the location of a list of target's jar files.
For these locations I have an aspect that runs on a list of targets (separately for each target using --aspects) and fetch the jar file path for each of them.
I've managed to get each jar file path in a custom output file (e.g. jar.txt) in each target's output folder.
But this will mean I would need to go over each jar.txt file separately to get the location.
Is there a way to accumulate the jar files paths in a single file?
Something like:
Try and write to the same output folder with append command in the aspect. I'm not sure if a shared output folder is possible.
Create a synthetic target which depends on all the relevant targets, then run an aspect on this target and accumulate the jars and only write them at the root after the recursion is back.
Are 1. or 2. valid options?
What is the recommended strategy to accumulate data in bazel aspects output files?
Bazel doesn't provide facitlities in Skylark for accumulating information between targets that are not related to each other in the target graph (e.g. ones that are mentioned on the command line next to each other).
One possibility would be to write a Skylark rule that depends on all the targets you usually mention on the command line and built that one; that rule will be able to collate the classpaths from each Java target to a single file.
Another possibility is to tell Bazel to write build events (that includes all the outputs of all targets the specified build pattern expands to) to a file using the --experimental_build_event_{json,text,binary}_file. (The "experimental" will be removed soon.). The files contain instances of this message:
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto
Natan,
If I understand correctly, you want to transitively propagate the information from each aspect node out into a single result. To do this, build the transitive set in your aspect rule implementation and pass it via the "provider" mechanism [^1]. I wrote up some examples on bazel aspects, perhaps you'll find it useful[^2].
https://github.com/pcj/bazel_aspects/blob/master/aspects.bzl#L94-L104
https://github.com/pcj/bazel_aspects