Re: Windows mingw64 and cygwin builds broken

[Andy Moreton]

On Fri 13 Nov 2015, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Fri, 13 Nov 2015 10:18:22 +0000
>> 
>> Both the cygwin-w32 and mingw64 builds now need to be configured with
>> --without-dbus to avoid a crash when dumping.
>
> That's not what I intended.  It was supposed to work even when D-Bus
> is compiled in.  The code that supports w32 notifications and the
> related DEFSYM's are conditioned on non-Cygwin build and on D-Bus not
> being available.  When D-Bus _is_ available, then only the DEFSYM's in
> dbusbind.c were supposed to be visible, and those in w32fns.c
> invisible, together with their supporting code.  But somehow this is
> not working...
>
> Ah, I think I see the problem: makedoc doesn't take preprocessor
> directives into account.  I need to think how to fix that.
>
>> As users may want to use D-Bus with cygwin-w32 emacs (and possibly with
>> mingw64 emacs), a configure option is needed for the w32-notifications.
>
> No, I don't think we need a configure option.  The intent was to
> provide the native w32 notifications only if D-Bus is not available,
> because the former support only a small subset of the functionality.

That still leaves users without the ability to turn both off (unless
they patch the sources before building).

>> Can you also please explain what was wrong with the patch I sent, which
>> was simpler than your solution.
>
> It used the same DEFSYM twice in certain configurations, which I
> don't like.

Fair enough - I agree that while it "works" at the moment, it is
potentially fragile.

>> Does it make sense to build emacs with support for both D-Bus and
>> w32-notifications, and for the user to choose which is enabled at
>> runtime ?
>
> Not to me, it doesn't.  And anyway, this is a separate issue; how to
> fix the double definition of ':timeout' is unrelated to whether we
> want to support both D-Bus notifications and w32 notifications in the
> same build.  We could discuss the latter after we fix the former.

I've since tried the cygwin-w32 and mingw64 builds on a different
machine, where both builds succeed (however the two machines may have
dfferent sets of packages installed in each environment).

    AndyM