Re: Re: [PATCH 14/14] MINGW: config.mak.uname: auto-detect MinGW build from compiler

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 9, 2014, 07:04 UTC
Message-ID: <alpine.DEB.1.00.1410090848380.990@s15462909.onlinehome-server.info>
In-Reply-To: <20141009050318.GA17479@seldon>

Hi Marat,

On Thu, 9 Oct 2014, Marat Radchenko wrote:

Show 22 quoted lines

> On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
> > Marat Radchenko <marat@slonopotamus.org> writes:
> > 
> > > When crosscompiling, one cannot rely on `uname` from host system.
> > 
> > That may well be true, but is that limited to cross-compiling to
> > mingw?   Would it be generally true for any cross compilation,
> > wouldn't it?
> > 
> > What I am wondering is if it is a better solution to make it easier
> > to allow somebody who is cross compiling to express "Mr.  Makefile,
> > we know better than you and want you to do a MINGW build for us
> > without checking with `uname -?` yourself", i.e.
> > 
> > 	$ make uname_O=MINGW uname_S=MINGW
> > 
> > which would hopefully allow cross-compilation into other
> > environments, not just MINGW.
> 
> So, do you really want this patch to be changed from 5-liner into
> a full-blow system detection rewrite based on `cc -dumpmachine`
> instead of `uname`?

Junio's responsibility as a maintainer is to keep this project afloat for a broader audience than this patch series tries to reach. Keeping that in mind, a patch that fixes a broad issue (in this case, cross-compiling) *just* for one small use case (in this case, cross-compiling for Windows using MinGW) might need a very good argument to convince the maintainer that a broader solution is either not achievable or so much more complicated that it is completely outside of the scope of this patch series.

FWIW this is *exactly* what I pointed out here:

	https://github.com/dscho/git/commit/e31124d4e8ba4e48181306198648cdfe73ff9c30#comments
	Hmm. This is a very narrow solution to the underlying problem.
	Just think about cross-compiling for e.g. MacOSX. The solution
	presented in this commit works for MinGW, only for MinGW, and for
	MinGW alone. The commit message needs to do a much better job to
	make that clear.

And Junio actually pointed out that a broader solution is neither impossible nor complex: Junio hinted at the use of the conditional assignment "FOO ?= bar":

	https://www.gnu.org/software/make/manual/make.html#index-_003f_003d

IMHO it would make tons of sense to replace the := assignments in https://github.com/dscho/git/blob/e31124d4e8ba4e48181306198648cdfe73ff9c30/config.mak.uname#L3-L8 by ?= assignments.

Of course it is very obvious where the idea for the patch we are discussing here comes from: the current config.mak.uname has this:

	ifdef MSVC
		# avoid the MingW and Cygwin configuration sections
		uname_S := Windows
		uname_O := Windows
	endif

This could be cleaned up in the same run: to be assigned *before* the conditional assignments of uname_S. Likewise, the MINGW-specific part should be done by searching for "mingw" in CROSS_COMPILE, also before the block of the uname_* variable assignments.

Ciao, Johannes

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.