I'd like to release a new version of fedora-rpmdevtools and would like
to clean up the Perl spec template included in it a bit further in the
next version.
The remaining question is about handling $RPM_OPT_FLAGS (yes, again) in
non-noarch Perl module packages.
This has been discussed before, and some people feel it's good (must?)
to have the packages honor $RPM_OPT_FLAGS also when passed in a
non-default --target to rpmbuild, while some are not quite convinced
that it's a good idea to allow arch-dependent module packages to be
built with optimization flags different from what Perl was built with.
By default, CPAN packages get their optimization flags from Perl.
Current status: the current spec template in fedora-rpmdevtools as well
as some tools do honor $RPM_OPT_FLAGS, ie. possibly override what Perl
was built with if their --target's differ. The current spec template
has:
%build
CFLAGS="$RPM_OPT_FLAGS" %{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags} OPTIMIZE="$RPM_OPT_FLAGS"
Some redundancy here; it could be simplified into (and this is what I
was about to commit):
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
make %{?_smp_mflags}
Now, what's new: I was earlier under the impression that both
ExtUtils::MakeMaker and Module::Build allow overriding the optimization
flags, but it turns out that's true only for ExtUtils::MakeMaker. I
haven't found a way to accomplish the above with Module::Build; with it,
it's possible to add things to the optimization flags, but not
_override_ AFAICT.
One example is the FE perl-Pod-Coverage package. On a box having i386
Perl installed, rebuilding it with --target i686 does not result in i686
$RPM_OPT_FLAGS being actually used (extra_compiler_options appears in
gcc's arguments before the ones from Perl, so at least -Ox from Perl
prevails, dunno about -march and friends).
So, opinions, what should we do about it?
- Discourage overriding optimization flags and use ones from Perl in all
arch dependent module packages (thus rendering "rpmbuild --target" with
them probably useless), or
- Leave things as is with the above redundancy cleanup to the spec
template applied (IOW, some packages honor --target, some don't), or
- Try to find a way to override the optimzation flags for packages using
Module::Build too, possibly patch/file bugs against upstream M::B, or
- Your idea here?
