From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: [RFC] Correctly handling MinGW-w64
Date: Mon, 17 Nov 2014 05:13:12 +0100 [thread overview]
Message-ID: <87ioieqxbb.fsf@wanadoo.es> (raw)
In-Reply-To: 546973D0.7050306@cs.ucla.edu
Paul Eggert <eggert@cs.ucla.edu> writes:
> Óscar Fuentes wrote:
>> +dnl We need to distinguish MinGW32 toolset from its spin-off
>> +dnl MinGW-w64. (This has nothing to do with word size.)
>> +MINGW_W64=no
>> +if test $opsys = mingw32; then
>> + AC_CHECK_DECL(__MINGW64_VERSION_MAJOR,
>> + MINGW_W64=yes,
>> + MINGW_W64=no,
>> + [#include <_mingw.h>])
>> + if test "$MINGW_W64" = "yes"; then
>> + AC_DEFINE([MINGW_W64], 1,
>> + [Define to 1 if you are using the MinGW-w64 toolset, regardless of word size.])
>> + fi
>> +fi
>
> Why does the above need to be in configure.ac? Can the relevant code
> just inspect __MINGW64_VERSION_MAJOR instead of inspecting MINGW_W64?
The key here is that __MINGW64_VERSION_MAJOR is defined on a header
(_mingw.h) so we would need to do
#if __MINGW32__
#include <_mingw.h>
#if __MINGW64_VERSION_MAJOR
...
> Or, if we prefer to use our own symbol, can we just put something like
> this:
>
> #ifdef __MINGW64_VERSION_MAJOR
> # define MINGW_W64 1
> #endif
>
> into ms-w32.h or into some other header specific to Microsoft Windows?
We don't have a header that is included by all the .c files, right?
(apart from configure.h, of course.) The need to test for MINGW_W64 can
occur anywhere.
OTOH, I would be happy to use any practical solution that avoids
configure.ac.
next prev parent reply other threads:[~2014-11-17 4:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 3:24 [RFC] Correctly handling MinGW-w64 Óscar Fuentes
2014-11-17 4:04 ` Paul Eggert
2014-11-17 4:13 ` Óscar Fuentes [this message]
2014-11-17 4:32 ` Paul Eggert
2014-11-17 14:59 ` Óscar Fuentes
2014-11-17 15:18 ` Paul Eggert
2014-11-17 15:42 ` Óscar Fuentes
2014-11-17 15:59 ` Eli Zaretskii
2014-11-17 18:23 ` Óscar Fuentes
2014-11-17 18:48 ` Eli Zaretskii
2014-11-17 19:04 ` Óscar Fuentes
2014-11-17 19:31 ` Eli Zaretskii
2014-11-17 22:19 ` Óscar Fuentes
2014-11-18 3:31 ` Glenn Morris
2014-11-18 3:50 ` Óscar Fuentes
2014-11-18 14:50 ` Stefan Monnier
2014-11-18 3:35 ` Eli Zaretskii
2014-11-17 15:57 ` Eli Zaretskii
2014-11-17 16:03 ` Paul Eggert
2014-11-17 16:34 ` Eli Zaretskii
2014-11-17 15:55 ` Eli Zaretskii
2014-11-17 16:02 ` Paul Eggert
2014-11-17 16:33 ` Eli Zaretskii
2014-11-17 4:05 ` Óscar Fuentes
2014-11-17 15:52 ` Eli Zaretskii
2014-11-17 15:51 ` Eli Zaretskii
2014-11-17 16:04 ` Óscar Fuentes
2014-11-17 16:35 ` Eli Zaretskii
2014-11-17 17:34 ` Óscar Fuentes
2014-11-18 8:24 ` Stephen Leake
2014-11-18 15:50 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ioieqxbb.fsf@wanadoo.es \
--to=ofv@wanadoo.es \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.