Skip to content

Conversation

@yanok
Copy link
Contributor

@yanok yanok commented Dec 4, 2025

There are two commits:

  • the first one is a very naive approach, just setting the CC variable to whatever the toolchain says is the compiler binary. This is clearly not enough for all cases, for example this doesn't work with toolchains_llvm for me.
  • the second one tries to be more sophisticated, also getting the compiler options from the cc_toolchain.

None of them are perfect, since the compiler options have to be filtered, also I haven't yet tested if it works on all platforms and whether cross-compilation works (not sure if it worked before this PR though, probably not).

Maybe we invert the direction here and instead of trying to give D compiler the correct way to call CC, try to link using the standard cc_common.link action, adding the standard D libraries to the inputs.

yanok added 2 commits December 4, 2025 17:33
Use `find_cpp_toolchain` from bazel_tools to find the current cc
toolchain and use the compiler from it for linking.

This is a bit naive, since we might need to add more flags to it.
But it seems to be enough with the local toolchain from rules_cc.
Try to be smarter about linking: use the cc_toolchain to get the
linking flags, filter some flags out and then pass the result
to the D compiler.

This works slightly better, allowing to use `toolchains_llvm` bazel
module.
@dcarp
Copy link
Collaborator

dcarp commented Dec 5, 2025

Thank you for the PR.

Maybe we invert the direction here and instead of trying to give D compiler the correct way to call CC, try to link using the standard cc_common.link action, adding the standard D libraries to the inputs.

I think this would be the right approach!

Also, please rename the branch to something containing windows and macos so that CI will test the PR for those platforms too.

@yanok
Copy link
Contributor Author

yanok commented Dec 5, 2025

Maybe we invert the direction here and instead of trying to give D compiler the correct way to call CC, try to link using the standard cc_common.link action, adding the standard D libraries to the inputs.

I think this would be the right approach!

I'm not completely sure. From the rules_cc PoV it's likely the right thing to do, since otherwise extracting out the bits we need out of cc_toolchain definition is tricky. OTOH, I see some issues with that:

  1. If goes against the D ecosystem, where pretty much everyone let's a D compiler to call a C compiler in the right way to link.
  2. I'm not sure about DMD, but LDC supports having several versions of druntime/phobos, and one can pass --link-defaultlib-{debug,shared} to pick one. This would have to be done on the level of bazel rules with cc_common.link approach. It's pretty trivial though, so probably not an issue.

Also, please rename the branch to something containing windows and macos so that CI will test the PR for those platforms too.

Uh, I didn't know CI triggers based on the branch name :) I will. I'd have to create a new PR for it though, right?

@yanok
Copy link
Contributor Author

yanok commented Dec 5, 2025

Opened #133 (almost the same, just another branch name + empty line added to make buildifier happy)

@dcarp
Copy link
Collaborator

dcarp commented Dec 5, 2025

Uh, I didn't know CI triggers based on the branch name :) I will. I'd have to create a new PR for it though, right?

This to reduces the CI resources consumption.
I think we can close this one as you have #133 now.

@dcarp dcarp closed this Dec 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants