Hi Martin,
On 29/08/2018 09:59, Martin Storsjö wrote:
On Aug 29, 2018, at 10:15, Jacek Caban <ja...@codeweavers.com> wrote:
On 29/08/2018 08:20, Martin Storsjö wrote:
On Aug 29, 2018, at 05:27, Liu Hao<lh_mo...@126.com> wrote:
在 2018/8/29 4:36, Tom Ritter 写道:
I hit this issue compiling ICU as part of Firefox, where they had a
variable named 'daylight'.
https://unicode-org.atlassian.net/browse/ICU-20100 was filed to change
the variable name; but I wanted to bring it up since these types of
defines are inevitably cause more breakage in the future...
I have no idea about what issue this was put in to address, nor any
opinions about how to fix it, I merely wanted to raise the concern
since it tripped us up.
Probably the macro `daylight` should be removed.
Yes, ideally - suggestions are welcome.
MSVC doesn't support 'daylight' symbol in recent version. Ideally we'd do the
same and just remove the macro. Do you have a sense about how bad that would be
for existing applications?
I'm not sure if specifically daylight is necessary anywhere,
Maybe we could remove it and revisit if it causes too much damage.
but at least "timezone", which also isn't exposed by MSVC, would break Qt if
we were to remove it. Qt has got a wrapper that looks like this:
static int qt_timezone() {
#if defined(_MSC_VER)
long offset;
_get_timezone(&offset);
return offset;
#elif defined(Q_OS_BSD4) && !defined(Q_OS_DARWIN)
[...]
#elif defined(Q_OS_INTEGRITY)
return 0;
#else
return timezone;
#endif
}
I'd say that Qt should check for _WIN32 instead of _MSC_VER here and use
_get_timezone in mingw builds. It would then work the way it's intended
to be done on Windows. We even have a warning attribute suggesting that.
Patches that you sent are an improvement over current solution, so I'm
fine with taking them. They look good to me, thanks.
I'd still prefer to just drop those symbols. MS did that, having much
bigger user base, and people adopted. We're targeting MS crt, which
doesn't have clear backward compatibility support, so it seems
reasonable to follow their changes. Expecting developers to make small
changes when porting to new crt (ucrt in this case) is also not
unreasonable. That said, I'd prefer dropping, but I'm not sure we should
do that. I don't have enough information to estimate the damage it would
cause.
Thanks,
Jacek
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
