Rule-based toolchains add unnecessary include flags to assemble actions

[davidbalbert]

Old-style toolchains add added include flags in to preprocess_assemble, but not assemble (see get_legacy_features).

Rule-based toolchains use source_compile_actions, which includes both preprocess_assemble and assemble.

This can break toolchains that want to use as for assemble and gcc/clang for preprocess_assemble: it broke as from GNU binutils 2.36.1 for me.

[keith]

I've noticed this too but haven't seen issues with clang. Have you tried it with an assmbler where it does end up failing?

[davidbalbert]

I did have an internal change that passed CI with GNU as, but as soon as I noticed this issue, I rolled back to using gcc for assemble actions and didn't investigate further.

I'm replacing our existing toolchains with rules-based toolchains and I want to minimize the risk of breaking something that isn't caught by CI. Using as seemed too risky with the current behavior.

[davidbalbert]

Whoops, I spoke too soon. This did indeed break CI with GNU as. Rolling back to using gcc for assemble actions was necessary. Updated the ticket description.

[davidbalbert]

Apologies for multi-posting.

When I was attempting to move to as, I noticed that compile_actions is defined like this:

cc_action_type_set(
    name = "compile_actions",
    actions = [
        ":cpp_compile_actions",
        ":c_compile_actions",
        ":assembly_actions",
        ":objc_compile",
    ],
)

It would be nice to either add a new set, or (even better, if possible) modify this one to contain preprocess_assembly rather than assembly_actions.

Most of my cc_args add include paths, and needed to ignore assemble. I ended up defining my own set to deal with this.

[armandomontanez]

Outside of the ability to call an as tool directly through the build, is there anything specific to be gained here? I'd say you're right from a correctness perspective, but the side effect is that if we restore this .s and .S files will be handled differently in ways that are quite subtle.

What's your motivation for trying to use as directly instead of doing assembly through the gcc/clang frontends?

[davidbalbert]

My motivation is to have unsurprising behavior: building .s with the assembler and .S with the compiler frontend is what most people expect. I'm also trying to minimize arg churn as I move us to our new rules-based toolchains. That said, using gcc for assemble isn't the end of the world for us.

I will note that you have the subtile differences in behavior right now: Bazel behaves differently depending on what API the toolchain is defined with.

[armandomontanez]

Yes, I have no objections to addressing this, I just wanted to make sure this wasn't blocking use cases I was unaware of.

[davidbalbert]

👍 yup, makes sense. thanks for being willing to consider!