Bug 1543394

I have risen the topic to the Ruby upstream [1]. And part of the answer was:

> Options given to configure as XCFLAGS and XLDFLAGS are used to build ruby itself, but not for extension libraries.

Now the question is how to use these with the macros proposed by you. The issue is, that they won't work with the standard %configure macro. That gives space to making mistakes.

Also, not sure if other languages supports something like X.+FLAGS macros or this is just Ruby specific.


[1] https://bugs.ruby-lang.org/issues/14422

(In reply to Vít Ondruch from comment #1)
> I have risen the topic to the Ruby upstream [1]. And part of the answer was:
> 
> > Options given to configure as XCFLAGS and XLDFLAGS are used to build ruby itself, but not for extension libraries.
> 
> Now the question is how to use these with the macros proposed by you. The
> issue is, that they won't work with the standard %configure macro. That
> gives space to making mistakes.

Almost certainly, you need to change code in the builder.  Ideally, there would be run-time detection for using different flags when running under rpmbuild and when not.

(In reply to Florian Weimer from comment #2)
IOW the X flags won't help at all, since we don't want to have some configuration for interpreted and different configuration of plugins plugins, but we want to have the same configuration flags for interpreter and plugins build via rpmbuild and different flags for plugins build by the language package manager.

It won't work without modifications of the interpreted plugin manager and I don't know who would implement the necessary changes :/

Rust and Cargo don't directly know anything about how non-Rust code will be compiled.  Any crate can have a build.rs script, and that can do completely arbitrary things.

Usually those build.rs scripts will use the "cc" crate though.  This does look in the environment for CFLAGS/etc, and maybe we could teach it to look elsewhere, but I don't know how we would integrate rpm macros into this.

[cc]: https://crates.io/crates/cc

What's the status here?
We can hack up something specific to Python if this problem be solved generally.

With the change in bug 1548397, we can now simply filter out all -specs= arguments.  This might change in the future, but for now, we can have a much simpler implementation.  I'll submit a patch for that, hopefully later today.

Created attachment 1402578 [details]
Second proposed patch

This patch depends on the -z now change in bug 1548397.  It filters out the -specs= arguments we do not want hard-coded into extension builders.

(In reply to Florian Weimer from comment #7)
> Created attachment 1402578 [details]
> Second proposed patch
> 
> This patch depends on the -z now change in bug 1548397.  It filters out the
> -specs= arguments we do not want hard-coded into extension builders.

Any comments on this approach?  It doesn't avoid the hard-coding, but I got the feeling that we don't want to patch out the build-flag-capturing logic in the upstream code.

I have to build Ruby with the original flags, including the -specs= option + some other options which are added by Ruby configuration process. They gets baked into rbconfig.rb and later provided as default when people are installing gems via "gem install".

So I am not sure how should I benefit from these new macros? Should I go and try to s/%{cflags}/%{extension_cflags}/ in rbconfig.rb? Not sure this will work and provide reliable results.

May if there was opposite, set of the flags I should definitely drop from the rbconfig.rb. Not sure.

Frankly, I don't like the idea of tweaking rbconfig.rb.

(In reply to Vít Ondruch from comment #9)
> Frankly, I don't like the idea of tweaking rbconfig.rb.

You would have to change mkconfig.rb anyway.

Could we patch mkconfig.rb so that the generated rbconfig.rb file reads overrides for those settings from files at specific locations?  Then we ship two subpackages with different defaults, and only one would pull in annobin.

We realized that avoiding the dependency on annobin and redhat-rpm-config could not be implemented without changes to extension builders, and we received little support for that from the respective package maintainers.  As a result, it does not make sense to add separate build flags in redhat-rpm-config.

Extension builders which hard-code the distribution CFLAGS should add a dependency on redhat-rpm-config and gcc (and gcc-c++ if applicable).

Bug 1634784 is a downstream requirement for this change, so reopening.

Created attachment 1513332 [details]
Proposed patch with documentation

This patch is essentially unchanged from the second patch, but now also includes documentation.

Excellent! Small nitpick:

{%extension_cxxflags} -> %{extension_cxxflags}

Created attachment 1513414 [details]
Patch with typo fix

Fix the documentation typo mentioned in comment 14.  Thanks.

Experimental PR for python3: https://src.fedoraproject.org/rpms/python3/pull-request/75

Florian, Panu, any chance that this patch can be merged?  Thanks.

I've no objections.

Thanks, merged.