jvolkman
Provide override for copts/linkopts in generated bzl lockfile
In primarily C++ codebases, it's possible you have global --copts that are incompatible with specific wheels that are built from their sdists. In this case you can likely set the linkopts/copts to negate the options, but there doesn't appear to be an override option to do that. In my mind it's similar to build deps where you can likely set them globally.
In our specific project we pass -fvisibility=hidden globally, which requires setting -fvisibility=default unless the projects expect this and manually annotate their code with it, and also -z,defs to make sure no library has missing symbols, which is incompatible with python extensions since it doesn't directly link libpython (and instead expects the necessary symbols to exist when it is loaded), which requires a -z,undefs in linkopts to negate.
You can override the build target in MODULE.bazel like here
And you can specify copts in your build target like here.
Does that help? I think we also support linkopts.
nice, i think that would work in a pinch, but in our case we have ~40 targets being built from sdists, so it might be a bit too much overhead
Okay. In that case we can add some default flags, similar to how we have default build deps.
On Mon, Jul 7, 2025, 9:01 AM Keith Smiley @.***> wrote:
keith left a comment (jvolkman/rules_pycross#167) https://github.com/jvolkman/rules_pycross/issues/167#issuecomment-3045727244
nice, i think that would work in a pinch, but in our case we have ~40 targets being built from sdists, so it might be a bit too much overhead
— Reply to this email directly, view it on GitHub https://github.com/jvolkman/rules_pycross/issues/167#issuecomment-3045727244, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA6MVJ2QXCDOLRKFPRY2RD3HKKXBAVCNFSM6AAAAACA4NJA2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANBVG4ZDOMRUGQ . You are receiving this because you commented.Message ID: @.***>
I think the most forward looking solution would be too add a custom feature to libraries always and users could define flags based on that feature in their toolchains. but practically speaking that would only work today for users who have custom C++ toolchains, which hopefully isn't that many but i imagine will be more in the future with the rules based toolchain