On Wed, Jun 30, 2010 at 3:34 PM, Charles Wilson
<cyg...@cwilson.fastmail.fm> wrote:
> 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.
Ok, sounds good.
