I would like to try to move the optflags definition into the macro file
to make it cleaner and easier to maintain, so to make that easier, I
wanted to start by removing unsupported arches, so there is less code
to move.
This requires the build system support VALAFLAGS. At least Meson and
Automake do.
Using -g is desired because it allows us to see Vala source files and
line numbers in backtraces when possible, falling back to generated C
code otherwise. Line numbers for generated C are almost always less
useful when debugging crashes.
If there are no .o/.a files to be distributed, this prevents
check_convert_bitcode from being called without a file argument,
in which case the first flag is going to be treated like the file
name, resulting in something like:
realpath: invalid option -- 'O'
Try 'realpath --help' for more information.
Usage: file [-bcCdEhikLlNnprsSvzZ0] [--apple] [--extension] [--mime-encoding]
[--mime-type] [-e <testname>] [-F <separator>] [-f <namefile>]
[-m <magicfiles>] [-P <parameter=value>] [--exclude-quiet]
<file> ...
file -C [-m <magicfiles>]
file [--help]
From https://bugzilla.redhat.com/2083296:
> The issue is that some packages break up the flags at spaces,
> in order to look for specific flags or to add flags of their own.
> The z3 package, for example, has some python code that does this:
>
> def exec_cmd(cmd):
> if isinstance(cmd, str):
> cmd = cmd.split(' ')
> ...
>
> The result is one of the commands in the list consists of a single tab character.
> When that is passed to the compiler, the compiler does not like it at all.
There appears to be new rpm behavior which adds
Requires(interp): /bin/sh
to this package, so we need to account for this in requires.txt.
We already have /usr/bin/sh in requires.txt, so this is not a
new dependency.
Packages which do not have %%build section but do also
compile and link test programs in %%check would fail because
no package note would have been generated.
We would try to regenerate the file whenever set_build_flags was used.
For packages which call %configure multiple times this would mean a
few times during build, and also in the build and check
preambles. Let's just simplify this and call it only in the build preamble.
https://src.fedoraproject.org/rpms/package-notes/pull-request/1
changes %_generate_package_note_file to be unconditional. This means we'll
always rewrite the file and will not use a stale version. (But the two
fixes are independent, even though they make the most sense together.)
I changed the definitions in package-notes to not do anything if
%_package_note_file is undefined. The other macros won't work if it is
not defined anyway, so this is quite natural. With this, undefining
%_package_note_file becomes the most comprehensive mechanism to disable
the feature. (Undefining %_package_note_flags still works so backwards
compat is preserved.)
The new mechanism will work once
https://src.fedoraproject.org/rpms/package-notes/pull-request/1 is merged.
But I don't think it is necessary to add a version requirement here, since
we're only providing the docs here.
This is already the default for ld.bfd, so this is effectively a no-op
for most packages. However, lld defaults different build-id algorithm
that the RPM build process does not support, so it needs this flag.
This flag can be overriden by setting the %_build_id_flags macro,
which packages could do if they wanted to use a more secure build-id
algorithm.
Also move this file to kernel-srpm-macros. Note that we need to require
a new kernel-srpm-macros release now, since that's where kmod.attr is
going to end up.
