mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Separate build rules (was Re: Mingw64)


From: Tony Theodore
Subject: Re: [Mingw-cross-env-list] Separate build rules (was Re: Mingw64)
Date: Tue, 29 Nov 2011 05:49:32 +1100

On 28 November 2011 01:12, Martin Gerhardy <address@hidden> wrote:
> Am 27.11.2011 10:47, schrieb Tony Theodore:
>>
>> On 12 September 2011 02:22, Martin Gerhardy<address@hidden>
[...]
>> As an aside, I'm not entirely sure about the multi-target approach any
>> more. Simple cases like openssl.mk are nice, but something like qt.mk
>> looks like a mess.
>>
>> Cheers,
>>
>> Tony
>
> Thanks a lot Tony,
>
> does that mean, that these patches will never make it upstream?

Never is a long time, but at this stage, I'd say it's very unlikely in
this form. My original thinking was to call the x64 experimental and
support a subset of packages, gradually building up full support, then
possibly switching over to mingw-w64 for i686 as well.

This is a nice idea, but there are several issues - two practical, one
subjective.

Multiple runtimes:
Supporting both mingw and mingw-64 seems like it will become more
difficult over time. The projects are diverging, having different sets
of apis, and even the i686 support is less of a drop-in replacement
than it used to be. The positive side here is that mingw-w64 have
released their v2, so there's now a more stable base to develop
against.

Multi-lib:
The mingw-w64 project seems to prefer building a multi-lib compiler.
The current design of the multi-target patches does not support this,
nor will it support using mingw-64 for both.

Simplicity:
Working with the multi-target environment loses the sense of
simplicity that makes mingw-cross-env so compelling. It's hard to
quantify, but there's a lot more indirection and it feels more like a
hack that works rather than something well thought through. I'm
personally quite happy with the learning, but Volker has a much better
sense of coherent design.


The first issue could be solved with extra resources, but the other
two require a fundamental rethinking of the approach.

Cheers,

Tony



reply via email to

[Prev in Thread] Current Thread [Next in Thread]