Bazel query as part of the build?

[Konstantin]

To figure the list of targets to request from the build we need to run Bazel query and massage the output with Python-like script. 

We can do it in two steps: 

1. run the script which executes Bazel query (or queries), calculates the list of targets and writes them to the file "targets.bzl"

2. run the actual build to act on that list;

Of course people would forget to run the first step, the build get executed on the stale list of targets and we get all kinds of weird build error reports.

I wonder if there is a way to embed the query into the build to make it all single invocation of Bazel. Ideally I would like to run Bazel query as part of repository rule execution.

Obviously I cannot simply invoke "bazel query" command from repository rule as Bazel can execute only one command at a time, but the existence of "genquery" gives me hope that there is a way to run query as part of the same build command.

Any leads?

Thank you!

Konstantin

[Dan Cohn]

I was going to suggest genquery, but you mentioned it, so I guess you're aware of it.  If a genquery() target is a dependency for another target, then I expect Bazel would execute it as a prerequisite for the target you've asked it to build.  With a macro, you could ensure that the proper target is always specified as a dependency. Just a thought.

[carpen...@gmail.com]

I believe you are not able to make global queryies from a genquery. 

Why not skip generating the targets and express it all in bazel? Make a py_binary which has data dependencies (we use rules_pkg to make output tarballs), and use bazel run. 

[David Turner]

One of the things we do to deal with similar problems with GN + Ninja is to put a "golden" version of the generated file in our source tree, and have an action that verifies that the build-generated version has the same content. If not, it will fail with an error message that tells the user how to fix the situation (which generally means copying the new build-generated version to the source tree, with Bazel you could even automate that with a `bazel run ...` command). Dependencies can be set up in a way that ensures this verification action is run before anything else that depends on the content of the file.

This is slightly annoying to implement and use, but it catches the problem locally (i.e. before submitting changes to CI/CQ) and provides human-readable instructions (plus sometimes a link to some documentation for the issue that gives more details).

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/16abda9a-f304-4907-a5e3-6848f99bf776n%40googlegroups.com.

[Alex Eagle]

If you decide to put a "golden" file in the source tree, write_source_files (https://docs.aspect.build/aspect-build/bazel-lib/v1.18.0/docs/write_source_files-docgen.html#write_source_files) is a full-featured and easy-to-use rule.

[Konstantin]

Yes,  "golden" version of the generated file is exactly what we resorted to after deliberation. 

Alex, thank you for the pointer at write_source_file rule!