Issue #21929 has been updated by mame (Yusuke Endoh). @alanwu Can we close this? https://github.com/ruby/ruby/pull/15695 is already merged. ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929#change-116704 * Author: jprokop (Jarek Prokop) * Status: Open ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_fl... which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_wi... -- https://bugs.ruby-lang.org/

Issue #21929 has been updated by jprokop (Jarek Prokop). While the MR allows to provide the flags in some manner, which is certainly a big part, in the PR there were mentioned some flags that are important to upstream to keep. See comment https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 , I see parallel here to for example setting the security-related branch protection flags for ARM architecture builds (or -fstack-protector, or other ...) https://github.com/ruby/ruby/blob/master/configure.ac#L915 . Currently, for Rust, all flag "groups": debug, security, and optimization are in a single variable. To continue with the branch-protection flag parallel as an example of a security-related compilation flag, that flag is set more or less unconditionally, as far as I can tell there isn't an easy way to disable it, and the CFLAGS can be freely overriden, as the branch-protection flag is appended if the example program compiles with the flag, no matter what was specified in CFLAGS. I'd maybe ask, would it make sense to split the single variable into multiple, make parts of it overridable and append the important flags like the `-C overflow-checks=on` unconditionally? If there would be such split, if program can be compiled with a flag, like the `-C overflow-checks=on`, it could always end up in the rustc compilation flag string, no matter what was specified on `./configure` step. This could allow more complete overriding of the rest of the flags (such as `-g`, `-C lto=thin`, ...), and using a dedicated ENV variable for the Rust flags as well (somthing similar to `CFLAGS="..."`) in addition to the existing configure flags, if the important flags are appended when for example the compilation test program can be successfully compiled. IOW, I feel like the current approach, despite being sufficient for, *could* be expanded further, to ensure more general and optimization flags can be fully overriden and to ensure that the important flags are always present. ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929#change-116741 * Author: jprokop (Jarek Prokop) * Status: Feedback ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_fl... which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_wi... -- https://bugs.ruby-lang.org/