On Tue, 2013 Oct 22 17:38+0800, JonY wrote:
>
> 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.
I never suggested replacing Cygwin-GCC with MinGW-GCC; if I want a
Cygwin binary, I'll use Cygwin-GCC. I'm not interested in producing
binaries that depend on the Cygwin DLL, however, so that's off the
table for me.
> > 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.
I'm not interchanging one for the other. I just don't want to use
Cygwin-GCC. (I do want to use the Cygwin *environment*, however, because
that lets me do nice things like run an sshd 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's easier to add e.g. /usr/i686-pc-mingw32/bin to the PATH than to
set all those variables.)
My point isn't that --host doesn't work, nor that it should go away, but
that it shouldn't be a requirement here---any more than it is when
someone builds 64-bit binaries on a system that identifies as 32-bit.
Could you be more specific on the "this" that would break Libtool? As
far as I'm aware, Libtool is perfectly capable of generating MinGW
libraries.
> > 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?
CXX and AR are standard build-environment variables (and the latter need
not be set if Autoconf can find ar.exe in the MinGW tool dir). I'm not
thinking of a stupid user here, but a user of any experience who wonders
why Autotools makes this process more complicated than it is.
> 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.
You consider CC to be a hidden variable?
> 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?
If the triplet is something novel that config.guess doesn't know about,
*that* would be a good argument to use --host/--build.
> 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.
CC is standard; --host, less so. And it's questionable why --host should
be needed at all when we're compiling binaries that will run on the same
system that built them.
> Like Jan says, this is a horrible hack, adds confusion. Any changes
> are purely cosmetic and of questionable value.
Not requiring users to go through the motions of a cross-compile to
build Win32 binaries on Win32 *adds* confusion?
> > Non-GCC compilers which define __MINGW{32,64}__? Are you referring
> > to Clang?
>
> Yes.
MinGW-Clang uses a different triplet from MinGW-GCC?
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
