qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 27/30] build: move compiler version check to meson


From: Peter Maydell
Subject: Re: [PATCH 27/30] build: move compiler version check to meson
Date: Fri, 9 Dec 2022 14:19:24 +0000

On Fri, 9 Dec 2022 at 14:09, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 12/9/22 12:52, Peter Maydell wrote:
> > The new code makes it much harder to move our compiler version
> > requirements forward in future, because there's no longer a simple
> > "check for normal clang X or apple clang Y" test where we can
> > bump up X and Y based on what's provided in the various host
> > platforms we have to support. Doesn't meson provide a way to do
> > the version check on the version number the way we were doing
> > previously?
>
> Yes, I could just do the check with #error just like before.
>
> For GCC I used the nicer "compiler.version().version_compare('>=x.y')"
> check.  For clang we have to deal with both upstream and Apple version
> numbers; it's also possible to check for __apple_build_version__ to
> distinguish between the two and then do version_compare(), but at that
> point it's easier to just use cc.compiles() and #error.
>
> While it's possible to learn the upstream version corresponding to Apple
> compilers with "c++ --verbose", it is not really machine-friendly so
> Meson does not attempt to parse it and neither did QEMU's configure script.
>
> So I went for the trick of using -Wpragma-pack, which was extracted from
> https://github.com/simd-everywhere/simde/blob/master/simde/simde-detect-clang.h.
>   The advantage is that you only have one check, the disadvantage is of
> course that it obscures what's going on.  I can add a clearer comment
> around the check, or switch to #error and add a pointer to
> https://trac.macports.org/wiki/XcodeVersionInfo where the mapping can be
> found, or really anything else that is your preference.

I think really I just don't want a check that is "we happen to
know that this particular option switch is supported only
from these versions onward", because as soon as we say
"OK, we can move forward to a clang 7 baseline" we either
need to search around for an equivalent clever trick, or
else we need to get rid of all this code anyway and have
the version number check. So I don't mind how we do this
as long as there's a straightforward bit of code that
currently has "6 "and "10" in it and where we can change it to
"7" and "11 "in future and it does what we intend.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]