All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
	qemu-devel@nongnu.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [PATCH] meson.build: Refuse XCode versions < v15.0
Date: Tue, 26 Nov 2024 11:35:57 +0000	[thread overview]
Message-ID: <Z0WyndfeK7RiZJIC@redhat.com> (raw)
In-Reply-To: <f3c726b6-403d-462b-9973-eb51a8447f94@linaro.org>

On Tue, Nov 26, 2024 at 12:11:43PM +0100, Philippe Mathieu-Daudé wrote:
> On 26/11/24 10:23, Daniel P. Berrangé wrote:
> > On Tue, Nov 26, 2024 at 09:57:15AM +0100, Philippe Mathieu-Daudé wrote:
> > > On 26/11/24 09:10, Thomas Huth wrote:
> > > > According to our support policy, we only support the two latest
> > > > major versions of macOS, and we already removed compatibility code
> > > > for older versions. However, it's still possible that people install
> > > > an older version of XCode on a recent version of macOS - which won't
> > > > be able to compile QEMU anymore, see for example the ticket here:
> > > > 
> > > >    https://gitlab.com/qemu-project/qemu/-/issues/2694
> > > 
> > > Wondering about this issue, it is possible to install concurrent
> > > XCode versions, which is useful i.e. when you build an application
> > > targeting multiple (and older) App Store releases. See:
> > > https://xcodereleases.com/
> > 
> > That's true of any platform. You can get many GCC versions for Debian
> > and Fedora too.
> > 
> > > Maybe we need to clarify our support policy that we only support
> > > the XCode released with the 2 latest major macOS versions?
> > 
> > We implicitly support the XCode versions that are the "default" with
> > the latest 2 macOS versions.
> 
> Implicit might not be sufficient for users, see #2694.

Well I'm not convinced the persno in that bug report would have
read the docs regardless. 

This patch takes care of making it explicit in a way that can't
be missed though.

> 
> > > > @@ -315,8 +315,8 @@ foreach lang : all_languages
> > > >        # ok
> > > >      elif compiler.get_id() == 'clang' and compiler.compiles('''
> > > >          #ifdef __apple_build_version__
> > > > -      # if __clang_major__ < 12 || (__clang_major__ == 12 && __clang_minor__ < 0)
> > > > -      #  error You need at least XCode Clang v12.0 to compile QEMU
> > > > +      # if __clang_major__ < 15 || (__clang_major__ == 15 && __clang_minor__ < 0)
> > > > +      #  error You need at least XCode Clang v15.0 to compile QEMU
> > > >          # endif
> > > >          #else
> > > >          # if __clang_major__ < 10 || (__clang_major__ == 10 && __clang_minor__ < 0)
> > > > @@ -325,7 +325,7 @@ foreach lang : all_languages
> > > >          #endif''')
> > > >        # ok
> > > >      else
> > > > -    error('You either need GCC v7.4 or Clang v10.0 (or XCode Clang v12.0) to compile QEMU')
> > > > +    error('You either need GCC v7.4 or Clang v10.0 (or XCode Clang v15.0) to compile QEMU')
> > > 
> > > BTW apparently CentOS 8 (which we don't support anymore IIRC)
> > > provides Clang 12.0.1, and also Ubuntu 22.04, Alpine 3.16.
> > > 
> > > I wonder if the relation with XCode __apple_build_version__ is
> > > always __clang_major__ + 3...
> > 
> > No, it isn't. It varies all over the place -
> > 
> > eg
> > 
> >  From xcode 11.3 to 11.4 they bump from llvm 8.0.0 to 9.0.0, while the
> > clang version goes from 11.0.0 to 11.0.3.
> > 
> >  From xcode 15.4 to 16.0 they from llmvm 16.0.0 to 17.0.6, while the
> > clang version goes from 15.0.0 to 16.0.0.
> > 
> > I can just about interpret a rule they're following, but relating that
> > to the upstream clang versions algorithmically is impossible.
> > 
> >    https://en.wikipedia.org/wiki/Xcode#Toolchain_versions
> 
> Doh...
> 
> Anyway, for this patch:
> 
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      reply	other threads:[~2024-11-26 11:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26  8:10 [PATCH] meson.build: Refuse XCode versions < v15.0 Thomas Huth
2024-11-26  8:57 ` Philippe Mathieu-Daudé
2024-11-26  9:23   ` Daniel P. Berrangé
2024-11-26 11:11     ` Philippe Mathieu-Daudé
2024-11-26 11:35       ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z0WyndfeK7RiZJIC@redhat.com \
    --to=berrange@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.