Can blaze spit out the command line that would have been run to compile a target?

[James Philbin]

Hi,

I'm trying to integrate YCM (https://github.com/Valloric/YouCompleteMe) into a Bazel repository. For this to work, YCM needs the set of include paths that would have been passed to the compiler for a given target. Is there any way of coaxing Bazel into giving this information?

Thanks!

James

[Brian Silverman]

I've had success generating a compile_commands.json file for Clang's tooling (which needs similar information) via extra actions. I'm planning to write up a wiki page about doing that some time, but for now the code I've got is at this gist.

--
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/d4204a05-0485-43ea-a99e-ed2384ffac0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Philbin]

Wow, magic stuff. Before I go down this route, why wouldn't it work to just enumerate all of the includes for the transitive closure of a target?

For some reason this bazel query doesn't seem to work though:

$ bazel query 'labels(includes, deps(//path/to:target))'

Any ideas?

Thanks,

James

[Brian Silverman]

That specific query doesn't work because includes aren't labels (see #825 for some discussion). Also, query operators filter the results of the query; you're still only going to get labels out of it. Something like `bazel query --output=proto deps(//path/to:target)` (or XML) will let you extract all of the includes attributes by writing a bit of code if you want to go that route.

However, just extracting includes attributes is not quite enough in general. You also have the various genfiles directories, the source directory itself, includes specified via copts, and possibly additional options from CROSSTOOL or --copt.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/04ca86aa-d322-4738-80df-d198615986bf%40googlegroups.com.

[James Philbin]

Ah, yes - makes sense. I'll have a look into this approach, thanks!

James

[byz...@gmail.com]

Hi Brian,
It sounds great! I saw your gist, but I have a silly question, how to use it with my bazel project?
Add the three targets into my top-level BUILD file?
Where is the target of extra_actions_proto_py?

On Thursday, March 17, 2016 at 9:15:38 AM UTC-7, Brian Silverman wrote:

[Brian Silverman]

You can add the three targets to any of your BUILD files. The only things which care about what package that is are the value you pass to --experimental_action_listener and the 'tools/actions/generate_compile_commands_action' string in generate_compile_commands_json.py.

extra_actions_proto_py is a py_library with the output from running protoc on src/main/protobuf/extra_actions_base.proto from Bazel's source tree. Auto-generating that would be nice, but I did it manually because it's the only protobuf in that codebase.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/5c303d33-6b81-44c7-a286-66d373192d7d%40googlegroups.com.

[byz...@gmail.com]

Thanks! It works as a gem!