[PATCH 0/1] mingw: fix uname -r test

[PATCH 0/1] mingw: fix uname -r test

[Johannes Schindelin via GitGitGadget]

In df5218b4c30b (config.mak.uname: support MSys2, 2016-01-13), I obviously
made the assumption that calling uname -r in MSYS2 would always yield a
version number starting with "2".

That is incorrect, though, as uname -r reports the version of the Cygwin
runtime on which the current MSYS2 runtime is based.

This sadly breaks our build as soon as we upgrade to an MSYS2 runtime that
is based on Cygwin v3.0.2.

Happily, this patch fixes that.

Johannes Schindelin (1):
  mingw: allow building with an MSYS2 runtime v3.x

 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 6e0cc6776106079ed4efa0cc9abace4107657abf
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-160%2Fdscho%2Fmsys2-3.x-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-160/dscho/msys2-3.x-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/160
-- 
gitgitgadget

[PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Recently the Git for Windows project started the upgrade process to
a MSYS2 runtime version based on Cygwin v3.x.

This has the very notable consequence that `$(uname -r)` no longer
reports a version starting with "2", but a version with "3".

That breaks our build, as df5218b4c30b (config.mak.uname: support MSys2,
2016-01-13) simply did not expect the version reported by `uname -r` to
depend on the underlying Cygwin version: it expected the reported
version to match the "2" in "MSYS2".

So let's invert that test case to test for *anything else* than a
version starting with "1" (for MSys). That should safeguard us for the
future, even if Cygwin ends up releasing versionsl like 314.272.65536.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 config.mak.uname | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.mak.uname b/config.mak.uname
index c8b0e34c31..0207e895a4 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
 	NO_GETTEXT = YesPlease
 	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
 else
-	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
+	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
 		# MSys2
 		prefix = /usr/
 		ifeq (MINGW32,$(MSYSTEM))
-- 
gitgitgadget

Re: [PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

[Junio C Hamano]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> So let's invert that test case to test for *anything else* than a
> version starting with "1" (for MSys). That should safeguard us for the
> future, even if Cygwin ends up releasing versionsl like 314.272.65536.

An obvious alternative is to do "2" -> "[23]" *and* update the else
to an explicit check for "1", *and* add an else that fails the build
when it sees "4" and other unknown ones.

I do not know how compatible MSYS2 runtime v4.x will be with the
settings the part inside the ifneq() we see here protects, but you
probably do, so I think this would be good enough.  The only case
that makes any difference is when v4.x _mostly_ satisifies but
slightly differs, affecting the built binary in a subtle way that is
not discovered right away.  But in such a case, the more cautious
"fail on '4' that we do not recognize" will not help much, as the
first reaction after seeing the error would be to copy the settings
that used to be OK with v2.x and v3.x anyway (which is what is being
done here---we start with the assumption that the support needed for
v3.x is largely the same as v2.x).

Will queue directly on top of... 'maint'?  'master'?

Let's say 'maint' and merge that up to 'master'.

Thanks.

>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  config.mak.uname | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/config.mak.uname b/config.mak.uname
> index c8b0e34c31..0207e895a4 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
>  	NO_GETTEXT = YesPlease
>  	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
>  else
> -	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
> +	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
>  		# MSys2
>  		prefix = /usr/
>  		ifeq (MINGW32,$(MSYSTEM))

Re: [PATCH 1/1] mingw: allow building with an MSYS2 runtime v3.x

[Johannes Schindelin]

Hi Junio,

On Sun, 10 Mar 2019, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > So let's invert that test case to test for *anything else* than a
> > version starting with "1" (for MSys). That should safeguard us for the
> > future, even if Cygwin ends up releasing versionsl like 314.272.65536.
> 
> An obvious alternative is to do "2" -> "[23]" *and* update the else to
> an explicit check for "1", *and* add an else that fails the build when
> it sees "4" and other unknown ones.

Right.

> I do not know how compatible MSYS2 runtime v4.x will be with the
> settings the part inside the ifneq() we see here protects, but you
> probably do, so I think this would be good enough.

I would expect Cygwin v4.x (which will be the basis for MSYS2 runtime
v4.x) to be as diligent as Cygwin v3.x in maintaining as much backwards
compatibility as possible.

Read: I trust "2 or higher" to be the answer.

> The only case that makes any difference is when v4.x _mostly_ satisifies
> but slightly differs, affecting the built binary in a subtle way that is
> not discovered right away.  But in such a case, the more cautious "fail
> on '4' that we do not recognize" will not help much, as the first
> reaction after seeing the error would be to copy the settings that used
> to be OK with v2.x and v3.x anyway (which is what is being done
> here---we start with the assumption that the support needed for v3.x is
> largely the same as v2.x).
> 
> Will queue directly on top of... 'maint'?  'master'?
> 
> Let's say 'maint' and merge that up to 'master'.

Thank you.

For the record, the really super ugly hack I plan on implementing to make
Windows builds pass in our Azure Pipeline is to build the
git-sdk-64-minimal artifact (which contains all of the stuff needed to
compile Git for Windows, such as `make`, `gcc`, etc) is to "install" a
different `uname`: as the MINGW binaries live in `/mingw64/bin/` (unlike
the MSYS binaries, which live in `/usr/bin/`, like `uname.exe`), I can
write the following script into `/mingw64/bin/uname`:

	#!/bin/sh

	case "$*" in -r) echo 2.bogus;; *) /usr/bin/uname "$*";; esac

This will be the stop-gap solution for branches that are based on commits
*without* this here patch.

It's ugly alright, but the only hack I could think of that actually will
work.

Ciao,
Dscho

> 
> Thanks.
> 
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  config.mak.uname | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/config.mak.uname b/config.mak.uname
> > index c8b0e34c31..0207e895a4 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -569,7 +569,7 @@ ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
> >  	NO_GETTEXT = YesPlease
> >  	COMPAT_CLFAGS += -D__USE_MINGW_ACCESS
> >  else
> > -	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
> > +	ifneq ($(shell expr "$(uname_R)" : '1\.'),2)
> >  		# MSys2
> >  		prefix = /usr/
> >  		ifeq (MINGW32,$(MSYSTEM))
>