-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Support customizable JIT_RUST_OPTFLAGS for JIT builds #15695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| $(RUST_LIB): $(srcdir)/ruby.rs | ||
| $(ECHO) 'building $(@F)' | ||
| $(gnumake_recursive)$(Q) $(RUSTC) --edition=2024 \ | ||
| $(JIT_RUST_OPTFLAGS) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure whether changes in this field are desirable, but since adjustments around framepointer, debuginfo and others are specified in the fedora rust flags, I preferred more cautious approach here and included the compilation flags here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm positive on this since it helps with packaging.
Instead of patching these in configure.ac and the associated makefiles, it is more comfortable to set them during configure as a linux distribution maintainer.
Note there is no need for patching already. You can do env RUSTC="rustc -flag -flag" configure to add additional flags. This is what we do on CI to pass +1.58.0 to test an older rust version. It's still nicer to have a dedicated option, though.
| $(RUST_LIB): $(srcdir)/ruby.rs | ||
| $(ECHO) 'building $(@F)' | ||
| $(gnumake_recursive)$(Q) $(RUSTC) --edition=2024 \ | ||
| $(JIT_RUST_OPTFLAGS) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should rename this RUSTFLAGS and have the corresponding lowercase version. It's already not just optimization flags (-g) and the ruby crate might gain non-JIT rust code in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried general RUSTFLAGS and it gets taken over by cargo at some point affecting mmtk CI due to some dependency having -C embed-bitcode=no which is incompatible with any LTO https://github.com/jackorp/ruby/actions/runs/20429672830/job/58697416079#step:14:143 , and JIT_RUST_FLAGS already exist.
I think it would be nice to have full RUSTFLAGS, but at the time I cannot do necessary work in time for Ruby 4.0.
Add `JIT_RUST_OPTFLAGS` env variable and `jit_rust_optflags` configuration support to allow customizable optimization flags for rustc JIT builds.
78f828f to
2b4c382
Compare
|
Sorry, this won't make it in time for 4.0. It's simply too close to release. You can pass flags without patching by passing RUSTC through the environment in the meantime. |
Co-authored-by: Alan Wu <[email protected]>
Co-authored-by: Alan Wu <[email protected]>
Add
JIT_RUST_OPTFLAGSenv variable andjit_rust_optflagsconfiguration support to allow customizable optimization flags for rustc JIT builds.When building rust bits, distributions might have their own preferred flags. For example, in Fedora, there are RUSTFLAGS available by the environment variables during RPM build. Cargo listens this env variable, these flags are set in addition to a custom profile with further RPM specifics.
rustchowever has to have the flags provided via CLI, in order to make those configurable, thare is new JIT_RUST_OPTFLAGS introduced for jit.These are implemented as JIT rustc specific.
I hit a problem with mmtk, where there is
-C emit-bitcode=noset somewhere in the dependencies (the libc crate possibly), which cannot be set with LTO at the same time, otherwise I'd go with setting RUSTFLAGS as env variable to fully mimic CFLAGS style of flags inside configure.ac and filling that for the rustc builds in the makefiles.One of the main motivations here is that Fedora uses different set of Rust flags than might be desirable from upstream defaults:
Instead of patching these in configure.ac and the associated makefiles, it is more comfortable to set them during configure as a linux distribution maintainer.