[ITP] mingw-w64

[Charles Wilson]

On 6/30/2010 2:53 PM, NightStrike wrote:
> On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote:
>> Hmm. So, big picture, we have possibly three different mingw-ish compilers,
>> and you're currently attempting to shepherd the first one, while being
>> mindful of future issues related to simultaneous installation of both of the
>> first two:
>>
>> (1) mingw64-derived, multilib, default 64bit
>> (2) mingw64-derived, multilib, default 32bit
>> (3) mingw.org-derived, non-multilib, only 32bit
>
> Is there any reason why there wouldn't be non-multilib versions of our
> stuff?

I don't really mind either way. I first raised the question of whether 
JonY's package would support -m32  or just -m64. His answer was -m64 
only, but then he almost immediately released a revision #2 that was 
multilib.

I assumed that would be the "only" version, but in the NEXT email 
exchange, he stated he was "saving" the /i686-w64-mingw32/ directory 
tree for the (multilib?) version that would default to -m32.

Now, maybe his original plan was to propose two separate non-multilib 
compilers, and he didn't think through the implications TO that plan 
that switching to multilib would cause.

But again, I don't care either way: one multilib with a specific 
default: fine.

Two non-multilibs, one for w64 and one for w32: fine.

Two multilibs, basically identical except for the different default (and 
the duplicated /{x85_85|i686}-w64-mingw32/ installation trees): also fine.

THAT's up to JonY.  He seems to have settled on the third of these 
options (especially given how the pthread stuff was packaged), but the 
other choices would also be A-OK IMO.

> How many permutations do you want to have?

Whatever's necessary to build both 64bit and 32bit binaries using your 
stuff.  What that actually means in terms of configure options...is 
JonY's decision.  I'm just trying to help him package what he wants to 
provide, in a way that will let setup.exe be happy, and not violate (too 
many) cygwin packaging standards.

I'm really not trying to pile extra work on JonY.

--
Chuck