Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/20/2020 05:11 PM, Kevin Kofler wrote:
> Ben Cotton wrote:
>> == Summary ==
>> This change will update all spec files in Fedora that use make and replace
>> the make invocations with either the %make_build or %make_install macros.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: <tstellar@xxxxxxxxxx>
> 
> I am opposed to this change.
> 
> Unlike other distros, it has always been Fedora policy to avoid this kind of 
> pointless macros and just spell things out, in the name of readability. I 
> think that should still be the way to go, also considering that:
> 

The benefits for using the macro are mentioned in the proposal, so this is not
just a cosmetic change.  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.

>> The %make_build macro enables parallel make builds using the -j option. 
>> In case a package does not build correctly with parallel make, then
>> parallel make will be disabled for that package by redefining the
>> %_smp_mflags macro like this:
>>
>>   %global _smp_mflags -j1
> 
> This does not work when some make targets (typically, the default "all" 
> target) support parallel make and others don't.
> 

I agree with this, and I will update the proposal to use %make_build -j1 instead.

> Additionally, how do you determine that "a package does not build correctly 
> with parallel make"? Parallel make failures are race conditions and thus not 
> reproducible. The builds can fail or succeed at random. The only safe 
> approach is to assume that a package that does not use %{_smp_mflags} at 
> this time probably omits it for a reason.
> 

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.

>> All changes will be submitted to dist-git repositories via pull requests.
>> Pull requests will be merged after 1 week if there are no objections or
>> earlier if approved by the package maintainers.
> 
> What is the point of making such a purely cosmetic change as a mass change 
> to all packages, with the potential of breaking things?
> 
>> == Benefit to Fedora ==
>> * Reduced build times: Using the %make_build macros enables parallel make
>> builds which will reduce build times for Fedora packages.
> 
> That is not true. The guidelines and templates clearly specify use of 
> %{_smp_mflags}, so IMHO it is safe to assume that those packages that 
> actually support parallel build already use %{_smp_mflags} and hence will 
> not start building any faster.
> 

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.


> As for those packages that do not currently use parallel build, see above: 
> you have to assume that they omit it for a reason. It is unsafe to enable it 
> behind the maintainer's back (giving them only 1 week to object, if they 
> even realize that %make_build invisibly enables %{_smp_mflags} to begin with 
> – IMHO, such hidden flags must be considered harmful).
> 
>> * This will make it easier to enforce consistent build flag usage across
>> all of Fedora.
> 
> What kind of build flags? Compiler flags? The valid way to set those depends 
> on the build system used. Passing make CFLAGS="…" with no knowledge of what 
> the makefile looks like is inherently unsafe: it can override required flags 
> set by the build system or a handwritten makefile, it can also end up being 
> ignored entirely. Usually, the right way to set flags is before the build 
> system or configure script invocation, not in the make step at all. (The 
> build system then hardcodes the flags in the makefile, so you do not have to 
> pass them again in the make step.)

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.

-Tom

> 
>         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
> 
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux