[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
From:       Kevin Kofler <kevin.kofler () chello ! at>
Date:       2020-06-22 21:05:40
Message-ID: rcr6f5$2b13$1 () ciao ! gmane ! io
[Download RAW message or body]

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@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]