Using custom CcToolchainConfig with Extractor.

[infirms]

Hey there, I've made custom config for GCC/Clang in bazel, but when i'm trying to extract compile_commands Extractor is using default toolchain(in my case msvc). Is there any workaround to make it using custom toolchain?

[Chris Sauer]

Hey, @infirms! Thanks for using the tool and writing in.

I'm pretty sure this will work; I know people are using it day to day and have used it myself. To help debug what's going on here, I'll need to know a little more about how you're setting the toolchain, and how you're invoking this tool with those same flags. But my expectation is that we'll be able to get this to work for you without any weird workarounds: if you feed the same flags into this tool that you build with (see README instructions about passing flags) then it should pick up your custom toolchain. If not, well, let's figure it out together :)

Cheers,
Chris

P.S. It's late my time, so I'm headed to bed. But I'll be back in the morning.

[infirms]

Thanks for creating this great tool and for the quick reply! I was just following this guide. I've created custom toolchain config, tweaked some things and standalone it works great and i get the desired result. For Extractor i was following the guide i.e: created BUILD rule for Extractor and pointed it to my project (and for now i haven't specified flags for it because i was testing it):

load("@hedron_compile_commands//:refresh_compile_commands.bzl", "refresh_compile_commands")

refresh_compile_commands(
    name = "refresh_compile_commands",

    targets = {
        "//src/client:client_main": "",
    },
)

When i compile my example project i'm doing it like this:

bazel build --config=compiler_config //src/client:client_main

When i run bazel run //:refresh_compile_commands it does the job right, but it uses default compiler that bazel has found in my system. I think that this may be caused by QUOTE:

I understand that i've not specified any compiling/linking flags for Extractor for now, but in my understanding it already should use the proper toolchain to extract compile_commands, so since it defaults to other toolchain my question is how to tell the Extractor to use my custom toolchain for extracting compile_commands?

And in confirming my theory that it was using msvc i saw warning that it doesn't understand -std=c++17 since msvc is using other syntax and compile commands are filled with msvc and crt headers e.g:

"file": "src/client/main.cpp",
    "arguments": [
      "C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.34.31933/bin/HostX64/x64/cl.exe",
      ... etc

[Chris Sauer]

heh, surprise! I'm still up :)

Love that you're exploring these custom toolchains. Thanks for replying back with more details!

[Chris Sauer]

So, the problem is that the tool isn't getting the --config=compiler_config you use to specify the toolchain when you build, so its analysis takes place without your toolchain!

[Chris Sauer]

If you always want to build with that toolchain, I'd just make those settings always apply in your .bazelrc. (Just remove all instances of :compiler_config, and you won't need --config=compiler_config when you build.)

If you just always want to analyze that target with that toolchain, instead tell the extractor about the flag by changing your refresh_compile_commands's targets to

    targets = {
        "//src/client:client_main": "--config=compiler_config",
    },

And if you just want to analyze with it sometimes, then just bazel run //:refresh_compile_commands -- --config=compiler_config

[infirms]

Thanks i've just fixed it the same way myself and with your reply i've confirmed that everything is correct now. Thank you!

[Chris Sauer]

If that works for you, could I get your help with a "communications backtrace"? The above is what I was trying to convey with this section of the readme. I'd love your help trying to figure out how to make it better!

And if one of those doesn't work for you, holler, and we'll figure it out together!

[Chris Sauer]

Huzza! Delighted to hear it. Still would love your help if you can think of ways we could make this better for future folks. I wish this had been even clearer for you and want to make it better for the next folks in your shoes.

[infirms]

I would be glad to contribute, will make the PR after thinking the best way explaining it.

[Chris Sauer]

Amazing. Thanks. Sometimes it's hard to explain an interface when one is too familiar with the implementation. Really appreciate your willingness to leave things better than you found them!