I had occasion to look at the valgrind use in spec files because we
might have an architecture regression downstream. I noticed that a lot
of packages have hard-coded lists of architectures on which valgrind is
available. Starting with Fedora 24, this lists is also available in the
%{valgrind_arches} macro provided by redhat-rpm-config.
%{valgrind_arches} is always safe to use if you do not run valgrind
during build, but only need valgrind-devel because it accurately
reflects the availability of these packages.
If you run valgrind during build (BuildRequires: valgrind), you may
encounter scenarios where it is supported only on a subset of
architectures for your tests due to valgrind limitations. Here is what
we use in glibc to set the valgrind support status:
# Default: Always run valgrind tests if there is architecture support.
%ifarch %{valgrind_arches}
%bcond_without valgrind
%else
%bcond_with valgrind
%endif
# Restrict %%{valgrind_arches} further in case there are problems with
# the smoke test.
%if %{with valgrind}
%ifarch ppc64 ppc64p7
# The valgrind smoke test does not work on ppc64, ppc64p7 (bug 1273103).
%undefine with_valgrind
%endif
%endif
(There are probably ways to express this in a less clumsy fashion.)
The idea is to never go beyond the set of architectures listed in
%{valgrind_arches}.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/7GJQDPCQ743DKJ3LAJFDDX3ZD6LOPB5N/
