* Tom Stellard:
>>> * It will make it easier to determine which packages disable or add
>>> compiler flags by doing a simple grep of the spec files.
>>> * It will make it easier for toolchain developers to experiment with
>>> adding new flags to the distribution as this can be done with a simple
On 2/10/23 00:07, Florian Weimer wrote:
I want to add documentation for this change, and found this proposal
self-contradictory.
== Summary ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages
I want to add documentation for this change, and found this proposal
self-contradictory.
> == Summary ==
> Create a corresponding macro for each compiler flag in the
> redhat-rpm-config macro file and create "extra flag" macros to make it
> easier for packages to add and remove compiler flags.
>
On Fri, 24 Jun 2022 at 09:32, Florian Weimer wrote:
> >>> With these new macros, the examples from above could be re-written as:
> >>>
> >>> compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
> >>> julia: %global _flag_glibcxx_assertions %{nil}
> >> Do you have some
* Tom Stellard:
> Or we could just leave it as is and document that the default complier
> behavior takes precedence over compiler flags. The proposed change
> doesn't actually make the problem worse, because the current method
> for removing compiler flags has the same problem: e.g.
>
> %global
On 6/24/22 01:32, Florian Weimer wrote:
* Tom Stellard:
On 6/7/22 02:18, Florian Weimer wrote:
* Ben Cotton:
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros
* Tom Stellard:
> On 6/7/22 02:18, Florian Weimer wrote:
>> * Ben Cotton:
>>
>>> This change will add new macros which will make it easier for packages
>>> to add and remove their own compiler flags. This strategy is already
>>> used to some extent with feature macros like %{_lto_cflags},
>>>
On 6/7/22 02:18, Florian Weimer wrote:
* Ben Cotton:
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these
Dne 07. 06. 22 v 11:10 Florian Weimer napsal(a):
* Vít Ondruch:
Dne 03. 06. 22 v 16:32 Tom Stellard napsal(a):
On 6/3/22 02:24, Vít Ondruch wrote:
Hi Tom,
Since you are looking into this and I like this proposal, have you
considered to look alto into `%extension_*flags`:
* Ben Cotton:
> This change will add new macros which will make it easier for packages
> to add and remove their own compiler flags. This strategy is already
> used to some extent with feature macros like %{_lto_cflags},
> %{_hardening_cflags}, etc, but these new macros will give packagers
>
* Vít Ondruch:
> Dne 03. 06. 22 v 16:32 Tom Stellard napsal(a):
>> On 6/3/22 02:24, Vít Ondruch wrote:
>>> Hi Tom,
>>>
>>> Since you are looking into this and I like this proposal, have you
>>> considered to look alto into `%extension_*flags`:
>>>
>>>
On 6/6/22 00:58, Panu Matilainen wrote:
On 6/3/22 13:43, Fabio Valentini wrote:
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote:
BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be
Dne 03. 06. 22 v 16:32 Tom Stellard napsal(a):
On 6/3/22 02:24, Vít Ondruch wrote:
Hi Tom,
Since you are looking into this and I like this proposal, have you
considered to look alto into `%extension_*flags`:
On 6/3/22 13:43, Fabio Valentini wrote:
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote:
BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be rather removed or not?
I agree that
Ben Cotton kirjoitti 2.6.2022 klo 22.27:
* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.
By the proposal owners, I presume? The guidelines should also be updated
to present the new
On 6/3/22 02:24, Vít Ondruch wrote:
Hi Tom,
Since you are looking into this and I like this proposal, have you considered
to look alto into `%extension_*flags`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_120-123
I have not considered this. Do you think
On 6/3/22 03:43, Fabio Valentini wrote:
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote:
BTW isn't the `_flag_` prefix too generic? And also, the initial
underscore implies that this is internal macro which should ideally not
be used. So should it be rather removed or not?
I agree that
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch wrote:
>
> BTW isn't the `_flag_` prefix too generic? And also, the initial
> underscore implies that this is internal macro which should ideally not
> be used. So should it be rather removed or not?
I agree that the "_flag_" prefix might be a little
Hi Tom,
Since you are looking into this and I like this proposal, have you
considered to look alto into `%extension_*flags`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_120-123
This is longstanding issue:
https://bugzilla.redhat.com/1284684
Where we have
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering
21 matches
Mail list logo
