All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Eric Sunshine" <sunshine@sunshineco.com>,
	"Atharva Raykar" <raykar.ath@gmail.com>,
	"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
	git@vger.kernel.org, pclouds@gmail.com
Subject: Re: [PATCH] makefile: update detect-compiler for newer Xcode version
Date: Fri, 6 Aug 2021 15:20:22 -0400	[thread overview]
Message-ID: <YQ2LdvwEnZN9LUQn@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq8s1eigto.fsf@gitster.g>

On Fri, Aug 06, 2021 at 11:11:31AM -0700, Junio C Hamano wrote:

> > So maybe we could add another case for "Homebrew clang"?
> 
> $ clang --version 2>&1 | sed -ne 's/ version .*//p'
> Debian clang
> 
> It might be necessary to cope with this "$VENDOR clang version"
> convention better with something like the following.

Good catch. Unfortunately your patch below isn't sufficient because
get_family() is broken, too. :(

It insists on there being an extra word after the actual version. There
is for gcc, but not for clang on my system:

  $ CC=gcc get_version_line
  gcc version 10.2.1 20210110 (Debian 10.2.1-6)

  $ CC=clang get_version_line
  Debian clang version 11.0.1-2

Doing this on top of your patch makes "./detect-compiler clang" behave
as expected:

diff --git a/detect-compiler b/detect-compiler
index a80442a327..fd388ae783 100755
--- a/detect-compiler
+++ b/detect-compiler
@@ -13,11 +13,11 @@ get_version_line() {
 }
 
 get_family() {
-	get_version_line | sed 's/^\(.*\) version [0-9][^ ]* .*/\1/'
+	get_version_line | sed 's/^\(.*\) version [0-9].*/\1/'
 }
 
 get_version() {
-	get_version_line | sed 's/^.* version \([0-9][^ ]*\) .*/\1/'
+	get_version_line | sed 's/^.* version \([0-9][^ ]*\).*/\1/'
 }
 
 print_flags() {

> I am afraid that this patch is being a bit too aggressive about
> LLVM, as I do not know if "$VENDOR LLVM version" is also a thing, or
> it is just oddity only at Apple, though.

I think even before this issue, all of the versioning of Apple's clang
is suspect. The "Apple LLVM" bit comes from Eric in:

  https://lore.kernel.org/git/20180318090607.GA26226@flurp.local/

But downthread we realized that the version numbers there don't match
the clang ones:

  https://lore.kernel.org/git/CAPig+cRQXQ_DowS2Dsc1x3TAGJjnWig7P4eYS4kQ+C2piAdSWA@mail.gmail.com/

Duy indicated in the cover letter:

  https://lore.kernel.org/git/20180324125348.6614-1-pclouds@gmail.com/

that the apple support was probably wrong, but it looks like nobody
stepped up in the meantime to fix it. In practice I think it mostly
works anyway because "clang4" is the only version check we have for
clang. So if we err "ahead" a few versions (which is what Apple's
scheme does), you only get bit if you have a pretty old version of
Xcode.

I think if we wanted to get it right, we'd need to encode into the
script some form of the version table here:

  https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_%28since_SwiftUI_framework%29

-Peff

  reply	other threads:[~2021-08-06 19:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06  8:06 [PATCH] makefile: update detect-compiler for newer Xcode version Carlo Marcelo Arenas Belón
2021-08-06 12:00 ` Bagas Sanjaya
2021-08-06 13:32   ` Carlo Arenas
2021-08-06 16:37     ` Eric Sunshine
2021-08-06 13:42 ` Atharva Raykar
2021-08-06 18:11   ` Junio C Hamano
2021-08-06 19:20     ` Jeff King [this message]
2021-08-06 20:52       ` [PATCH v2 0/3] detect-compiler: clang updates Junio C Hamano
2021-08-06 20:52         ` [PATCH v2 1/3] build: update detect-compiler for newer Xcode version Junio C Hamano
2021-08-06 20:52         ` [PATCH v2 2/3] build: clang version may not be followed by extra words Junio C Hamano
2021-08-06 20:52         ` [PATCH v2 3/3] build: catch clang that identifies itself as "$VENDOR clang" Junio C Hamano
2021-08-07  2:09           ` Jeff King
2021-08-07  2:02         ` [PATCH v2 0/3] detect-compiler: clang updates Ævar Arnfjörð Bjarmason
2021-08-07  2:15           ` Jeff King
2021-08-07  2:56             ` Ævar Arnfjörð Bjarmason
2021-08-07 14:13               ` Jeff King
2021-08-07 14:26                 ` Ævar Arnfjörð Bjarmason
2021-08-07 14:40                   ` Jeff King
2021-08-07 15:36                     ` Ævar Arnfjörð Bjarmason
2021-08-09 18:10                       ` Jeff King
2021-08-08  0:30                     ` Carlo Arenas
2021-08-09 18:08                       ` Jeff King

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=YQ2LdvwEnZN9LUQn@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=raykar.ath@gmail.com \
    --cc=sunshine@sunshineco.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.