Re: [Mingw-cross-env-list] MemoryBarrier needed for dbus

[Tony Theodore]

On 24 September 2011 10:42, Volker Grabsch <address@hidden> wrote:
> Tony Theodore schrieb:
>> Somewhat related, this is an interesting edge case. Driving home
>> tonight, trying to formulate the mingw-64 proposal in my mind, I
>> decided that any patches should apply to all targets. The author of
>> message [2] above, is one of the leads in the mingw-64 project, so I
>> imagine that that runtime already has support for this function.
>>
>> In the hypothetical multi-target scenario, how would we apply such a
>> patch? In this case, it would seem to make sense to patch windows.h
>> from w32api for the i686 target (assuming the x86_64 target does have
>> this) instead of in dbus.
>
> I propose to keep our current policy, which is: patches should always
> be portable, anything else is a "hack" and thus a $(SED) action. With
> portable I don't mean that it sould work with win32/win64, but also
> on any other platform.
>
> Although we do have exceptions from this rule [1], we should aim to
> reduce those rather than encouraging more of those "dirty" patches.
>
> I don't think this is very hard. In C/C++ we can use #ifdef, in the
> build script (configure script, makefiles, etc) we have various
> environment variables. So unless we don't find a corner case where
> all those methods don't work anymore, I don't think we should lower
> our standards for patches.

Agree entirely.

> The idea is that ideally, all patches would eventually move into
> upstream, or have at least a good chance of being a sensible proposal
> to upstream.

It's just that I would consider the mingw32 project to be the final
upstream for a patch like this. Patching the dbus sources fixes it for
dbus, patching win32api makes this function available to any project.
The latter seems to closer to the spirit of our policy.

Your thoughts?

Tony