On 6/3/22 13:43, Fabio Valentini wrote:
On Fri, Jun 3, 2022 at 11:25 AM Vít Ondruch <vondruch@xxxxxxxxxx> 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 too generic, but
what would be a better alternative?
Maybe something like _optflag_, to match what they are "collected
into" (i.e. %optflags)?
Also, macro names with single leading underscores are *fine* (see also
%_bindir, %_libdir, %_datadir, etc.).
Those with *double* leading underscores are the ones that should be
considered "internal" implementation details.
Once upon a time in past I can still remember, the following rule of
thumb for macro underscores was set [1]:
Use %__foo to set, %foo to get.
To me it looks like the entire set of suggested flags is basically
write-only values, and thus should have two leading underscores. So,
%__build_flag_whatever. Usage should always happen through the
non-underscored %build_cflags and friends, which can do their own
internal logic around this stuff, use Y only if X is enabled.
Other misc comments:
%_flag_flto_auto -flto=auto
Shouldn't this be %_flag_flto instead (or rather, %__build_flag_flto),
just like %_flag_o does not carry the optimization level in the name?
%_flag_werror_format_security -Werror=format-security
...and ditto for this, %__build_flag_werror whose default value is
-Werror=format-security ... except that unlike -flto, -Werror can appear
multiple times. Dunno.
What I guess I'm after, having an actual rule for the parameter -> macro
naming, one that could preferably be automated, would be beneficial. The
-Wl and -Wp related macro naming would need further consideration wrt that.
%_flag_pipe seems like the odd man out there because it doesn't actually
relate to code at all, but I guess consistency is the goal there.
[1] https://pagure.io/packaging-committee/issue/907
- Panu -
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
