Re: Support for MinGW compilers in the Cygwin environment

[JonY]

On 10/22/2013 09:43, Daniel Richard G. wrote:
> On Mon, 2013 Oct 21 18:13+0800, JonY wrote:
>>
>> Do not confuse Cygwin and MSYS, they are not interchangeable.
> 
> I know about MSYS; it's a good development environment, but not a
> complete system, and a lot less convenient to install. I'm concerned
> with using MinGW-GCC as shipped by Cygwin (not by the MinGW project) in
> the Cygwin environment, as opposed to Cygwin-GCC.
> 

This has nothing to do with MSYS vs Cygwin, your whole patch is messed
up, it needs to be shot down and burned like the bad idea it is. Cygwin
ships a CROSS COMPILER, mingw gcc is not a replacement for cygwin-gcc
like your use case suggests.

>> Use --host to set the cross compiler triplet instead.
> 
> The main goal of my patch was to eliminate the need to specify
> triplet(s) explicitly when using the MinGW compilers on Cygwin.
> 

Why would you even do that? Cygwin and MinGW ARE NOT INTERCHANGEABLE,
they just happen to run on Windows.

> In the same way that, on a Solaris machine I work with here, I can get
> 
>     $ ./config.guess 
>     i386-pc-solaris2.10
>     $ CC="cc -xarch=generic64" ./config.guess
>     x86_64-pc-solaris2.10
> 

--host does that already, why would you even want to set
CC/CXX/LD/AR/RANLIB/DLLTOOL manually when --host does exactly that? Not
to mention this will break libtool in horrible ways.

> it would be reasonable for config.guess (or possibly some other part of
> the toolchain?) to notice when we are using e.g. CC=i686-pc-mingw32-gcc
> and return a triplet reflecting that, rather than put the onus on the
> user to identify what can already be inferred from the environment.
> 

Did the user remember to set CXX? Did he remember to set AR too? Are you
implying the user is too stupid to know what he is compiling for?

Great. now there is a hidden variable called CC that I need to check
when supporting users, so much clearer than the highly visible --host
argument.

Now that you've done the i686-pc-mingw32 case, did you forget the
i686-w64-mingw32-gcc case too? After all, it would be nice if it did the
same too. Are you going to write another include-compile tests to see
which variant of mingw you are building for? What are you going to do if
other mingw implementations pop up?

> (Arguably, the same could be said for any number of [cross-]compilation
> scenarios, but what distinguishes MinGW-a-la-Cygwin is its accessibility
> and broad appeal as an alternative to the free-as-in-beer Visual Studio
> Express toolchain. The audience for this is much bigger than, say, the
> audience for building PowerPC binaries on Cygwin. So this would be a
> good place to make things "just work.")
> 

You are not making a convincing argument, you haven't given any insight
on why setting CC is better than --host other than highlighting the
plight of fictional users.

Like Jan says, this is a horrible hack, adds confusion. Any changes are
purely cosmetic and of questionable value.

>> You also run the risk of breaking non-gcc compilers.
> 
> Non-GCC compilers which define __MINGW{32,64}__? Are you
> referring to Clang?

Yes.

signature.asc
Description: OpenPGP digital signature