Henric Jungheim
2017-05-11 12:59:46 UTC
Now that wxWidgets has a stable release that supports VS2017
(the "v141" platform), is it time to start thinking about
upgrading the Microsoft compiler?
https://github.com/wxWidgets/wxWidgets/releases/tag/v3.0.3
There are a few changes necessary to get things working. If
I recall correctly, pull request #127 and #128 are
sufficient. They haven't been updated since last year so
they might not apply cleanly anymore. If there is interest,
I can take a look at refreshing them. The other "henricj"
pull requests might be required; it was a long time ago that
I looked at this stuff.
I keep a branch with a bunch of other changes synced with
the Audacity's "master" branch that includes the changes in
#127 and #128. VS2013, VS2015, and VS2015 all support both
Win32 and x64 builds, but I usually only test the x64 build
with the VS2017/v141 compiler since it takes forever to
build all the possible compiler and platform combinations
(the changes required for targeting Windows x64 are more
extensive since MS chose to make sizeof(long) == 4, whereas
sizeof(void*) == 8). This "x64" branch should include all
but the last few days of Audacity/master's changes:
https://github.com/henricj/audacity
As of right now, both v141/x64 and v141_xp/Win32 seem to
work.
This sort of infrastructure change is never fun, but
compilers get bug fixes like any other software and four
years is a non-trivial time for software to evolve.
Audacity was at version 2.0.3 or 2.0.4 or so when VS2013 was
released and I'm sure that some Audacity bugs have been
fixed since then. VS2017 Community should be free even for
corporate folks to use it for Audacity, since it is an open
source project.
Note that the changes for VS2015 and VS2017 are the same.
The v140 and v141 platforms are even binary compatible (i.e.,
using DLL compiled with one is usable from something
compiled by the other).
Regardless, it would probably be a good idea to take a close
look at pull request #127. The stdint.h and inttypes.h
headers were added before MS provided their own (in
VS2012...?). Overriding the compiler's header files is not
something to be done lightly. With VS2015 and later, it
causes all sorts of grief when other system headers find the
local headers instead of the official ones.
(the "v141" platform), is it time to start thinking about
upgrading the Microsoft compiler?
https://github.com/wxWidgets/wxWidgets/releases/tag/v3.0.3
There are a few changes necessary to get things working. If
I recall correctly, pull request #127 and #128 are
sufficient. They haven't been updated since last year so
they might not apply cleanly anymore. If there is interest,
I can take a look at refreshing them. The other "henricj"
pull requests might be required; it was a long time ago that
I looked at this stuff.
I keep a branch with a bunch of other changes synced with
the Audacity's "master" branch that includes the changes in
#127 and #128. VS2013, VS2015, and VS2015 all support both
Win32 and x64 builds, but I usually only test the x64 build
with the VS2017/v141 compiler since it takes forever to
build all the possible compiler and platform combinations
(the changes required for targeting Windows x64 are more
extensive since MS chose to make sizeof(long) == 4, whereas
sizeof(void*) == 8). This "x64" branch should include all
but the last few days of Audacity/master's changes:
https://github.com/henricj/audacity
As of right now, both v141/x64 and v141_xp/Win32 seem to
work.
This sort of infrastructure change is never fun, but
compilers get bug fixes like any other software and four
years is a non-trivial time for software to evolve.
Audacity was at version 2.0.3 or 2.0.4 or so when VS2013 was
released and I'm sure that some Audacity bugs have been
fixed since then. VS2017 Community should be free even for
corporate folks to use it for Audacity, since it is an open
source project.
Note that the changes for VS2015 and VS2017 are the same.
The v140 and v141 platforms are even binary compatible (i.e.,
using DLL compiled with one is usable from something
compiled by the other).
Regardless, it would probably be a good idea to take a close
look at pull request #127. The stdint.h and inttypes.h
headers were added before MS provided their own (in
VS2012...?). Overriding the compiler's header files is not
something to be done lightly. With VS2015 and later, it
causes all sorts of grief when other system headers find the
local headers instead of the official ones.