Support zig_module copts

[cerisier]

All zig compiler invocations support per module compiler options.
Therefore, adding a copts attribute to zig_module and gather them through the graph would allow forging the arguments at the right location when invoking the zig compiler.

However, this naming conflicts with the existing copts attribute of the zig_build descendent rules.
Currently, copts is used as C compiler flags and are prefixed with -cflags during zig compiler invocation.

I suggest that we rename the existing copts to cflags and use copts for Compiler options like it is the case for rules_swift for example.

WDYT ?

[aherrmann]

I think there are two points to this.

1. When rules_zig was initially started, per module compiler flags didn't exist, yet. Hence the current design controls most flags only at the build target (binary, library, test) level, rather than the module level. Now that Zig supports per module flags, the relevant flags (be it attributes or build settings) should indeed be made available at the module level.
2. So far rules_zig follows the same philosophy as std.Build in that Zig compiler flags cannot be set as strings directly by users, but instead they can be set through dedicated attributes or build settings. The motivation behind this is to be intentional about which flags should be controlled as attributs, build settings, or through the platform. Changing this can certainly be discussed, but it's orthogonal to per module flags. Edit: this is related to Support arbitrary Zig compiler flags through a zigopts attribute. #83, which proposes zigopts as a non-conflicting name.

[cerisier]

How would you approach this ?
Supporting arbitrary flags through a zigopts attribute seems contradictory with setting them with dedicated attributes ?

cc_library allows arbitrary copts even if those conflict with those already set by the toolchain, like -target in the case of clang.

I'm fine with zigopts. I'm a bit sad that every single ruleset has a different handling of this tho :(

rules_swift -> copts -> swiftc compiler options
rules_rust -> rustc_flags -> rustc compiler options
rules_go -> copts -> C compiler options

[steeve]

I agree with the spirit, but I think exposing each flag as an attribute or a build setting (worse imho) is untenable and user hostile.
I count about 40 different per module compilation flags.

on zigopts, rules_java calls it javacopts, rules_go uses gc_goopts, so I guess anything goes.

I do have a preference for copts though, but that's just me.

[aherrmann]

As a user of Zig's std.Build I have been annoyed by the lack of a zigopts equivalent. So, I'd be happy to have it in rules_zig, i.e. to address #83. For consistency though relevant flags that are configurable through attributes or build settings on zig_binary|test|*library should also be configurable on zig_module. The docs should also clarify that this is an advanced feature and that conflict with attributes and build settings will likely cause unexpected behavior.

Yeah, the inconsistent naming across the ecosystem is unfortunate. cflags and copts are very close and easy to mix up, so, that doesn't look like a very good choice to me. The migration story would also be pretty confusing, or stretch over several rules_zig versions.

Using zigopts and copts makes it pretty obvious what goes where.

[cerisier]

Closed by #530