Tom Stellard wrote:
> The benefits for using the macro are mentioned in the proposal, so this is
> not just a cosmetic change.
I have addressed those points further down in my message: I do not believe
that the proposed change will achieve the mentioned goals, and I think the
side effects are worse than what it can fix. See my detailed replies in the
remainder of both my previous message and this message.
> I think making it easier to standardize the build flags in Fedora is an
> important benefit as we currently have a gap in the project where packages
> that use make without a build system generator like autoconf or cmake do
> not have the correct build flags added automatically.
But there is no way RPM macros can address this problem, because there is no
standardized way to pass build flags to a handwritten makefile:
* The makefile may or may not honor environment variables. And passing -e to
make to try to force it may or may not work. (It can cause more problems
than it solves. In particular, -e is always detrimental for packages that
actually do use a makefile generator.)
* The makefile may or may not use standardized variable names such as
CFLAGS. I have seen makefiles hardcode the flags entirely or use arbitrary
names, such as COMPILER_FLAGS, GCC_FLAGS, COMPILER_OPTIONS or whatever.
(Or worse, they may use standard variable names with subtly different
semantics, e.g., CPP_FLAGS for C++ compiler flags.)
* Required flags may or may not be defined within CFLAGS. If they are, then
just overriding CFLAGS with the distro defaults will likely break the
package's build.
Handwritten makefiles are exactly the case where it is NOT safe to use a
stock macro such as %make_build. Such standardized macros can only possibly
work for packages using a popular build system, and for those, the configure
step is the right place to apply build flags.
> Packages will be tested using the koji-simple-ci job, which does a scratch
> build when a pull request is submitted. You are correct that this is not
> a 100% guarantee to catch parallel build issues. However, the downside
> of missing a parallel build issue is very limited as package maintainers
> can easily undo this change.
Sorry, I do not consider it acceptable to mass-break packages by default and
to require maintainers to explicitly unbreak them.
The only safe way is to assume that packages that do not use %{_smp_mflags}
omit it for a reason.
> I have not found this to be the case. I have implemented the proposed
> change in some packages already and I found packages that were not using
> %{_smp_mflags} that did benefit from parallel builds.
Then file bugs against those packages asking them to add %{_smp_mflags}. The
guidelines explicitly state that it should always be used if it works.
But don't be surprised if many of those bugs get closed as NOTABUG because
the %{_smp_mflags} were omitted or removed for a reason that you were not
aware of.
> I'm thinking about compiler flags, like CFLAGS or even possibly compiler
> variables, like CC and CXX. And they would not necessarily be passed as
> arguments directly to make. One option would be to have %make_build
> call the %set_build_flags macro which sets up environment variables with
> the correct flags.
Most handwritten makefiles ignore environment variables entirely. Something
like:
CFLAGS=-foo
or even:
CFLAGS+=-foo
takes precedence over environment variables. (Unless you pass make -e, which
will make it ignore even the += lines, and which can also cause other
problems.)
Only ?= honors environment variables, and many handwritten makefiles do not
use it, or at least not consistently.
And handwritten makefiles also do not necessarily use the conventional names
(CFLAGS, CC, CXX, etc.). They can use arbitrary variable names, or no
variables at all (i.e., everything hardcoded).
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
