2017-06-15 06:49:46 UTC
laptop. Testing that my x64 Audacity fork wasn't breaking
things outside of VS2017 was a bit painful even when VS2013
was still installed (apart from needing VS2013, all the
platforms, configurations, toolsets together generate
something like 40GB of build files). Anyhow, it seemed a
good excuse for setting up AppVeyor.
Here are VS2013, VS2015, and VS2017 builds for Win32/XP and
The GitHub source for the build is the x64 branch here:
The submodule points here:
Outside AppVeyor, the code should build with the full Visual
Studio or with just the Build Tools.
Microsoft only went from MSV++ 14.0 to 14.1 (or 19.0 to
19.10 for the actual compiler's version) in VS2015 to VS2017
and there weren't any additional changes needed to build
Audacity with VS2017. Microsoft is moving from a gigantic
change every two to three years model to more of a
continuous delivery model. VS2017 Update 3 is just around
the corner and MS is trying to reach full C++17 conformance
by the end of the year (as far as the v141 model with
permit; binary compatibility with v140 and existing v141
code is required).
The last time I brought this up, things got diverted into an
interesting but not perhaps entirely relevant to the core
issue (Microsoft's perfectly awful rand() implementation):
Is there some interest in getting some of the changes I've
made integrated into the main tree? If so which ones? I
updated pull request #127 and #128 since they have been open
since April 2016 and the tree has changed a bit since then.
I assume the primary interest would be in the minimal
changes needed to move beyond VS2013. CI for AppVeyor or
something similar might also be of interest..? There are
some isolated things that might also be useful (e.g,
reporting the compiler version in the Build pane of the
About dialog). Who should I be talking to?
-- There is already an appveyor.yml in the tree, so I had
AppVeyor use "topproj.yml" instead.
-- Since this was first set up for VSTS, and the wxWidgets
source needed to get in there somehow, a submodule was added
that points to a fork of wxWidgets that includes at least
some of the Audacity changes (if you have local changes
without using any SCM tols, then you have a fork without the
benefit of automatic tools).
-- The wxWidgets stuff is compiled as LTCG static libraries
that still do all their DLL exports. The resulting Audacity
executable therefore exposes the wxWidgets DLL interfaces,
but doesn't require a bunch of wx*.dll files hanging about.
This also make the Audacity executable bigger (roughly the
size of a dynamically linked Audacity.exe plus the wx DLLs).
One could save some space by not including those exports.
-- The x64 builds are done with default SDK (with
"PlatformToolset" v120, v140, and v141). The Win32 builds
are done with the 7.1A SDK (with "PlatformToolset" v120_xp,
v140_xp, and v141_xp).