#59 Predefine some symbol uniquely identifying MinGW-w64 toolchain in 32 bit builds

closed-wont-fix
nobody
None
8
2014-03-13
2013-09-30
Vadim Zeitlin
No

It would be nice to have some symbol other than __MINGW64_VERSION_MAJOR (which is not really obvious to discover and too long to use even after discovering it) to be able to distinguish MinGW-w64 from MinGW[32] in 32 bit builds. In 64 bits we have __MINGW64__ already, but in 32 bits everybody currently has to write some rather ugly preprocessor tests instead of just testing something like __MINGW64_TOOLCHAIN__.

Discussion

  • Kai Tietz
    Kai Tietz
    2014-03-13

    • status: open --> closed-wont-fix
     
  • Kai Tietz
    Kai Tietz
    2014-03-13

    You will need to rely on our macro. The named MINGW64 and the often mentioned MINGW32 macros are defined by gcc itself. They have absolutely no meaning regarding the used toolchain.
    See in our FAQ how to detect proper what runtime you are using and what predefined macros are existing.

     
  • Vadim Zeitlin
    Vadim Zeitlin
    2014-03-13

    The FAQ seems to recommend doing exactly what we do already which is, as I tried to explain in my original report, IMHO rather ugly (although having this in the FAQ certainly helps with discoverability, sorry for not noticing it there).

    My original idea was indeed to define a new macro at compiler level because I thought that MinGW-w64 used its own compiler build anyhow and so it wouldn't be a problem to do it. But if it is, defining something readable like __MINGW64_TOOLCHAIN__ in _mingw.h would still be worth it compared to the current __MINGW64_VERSION_MAJOR IMHO.