VS2017 RC

Building and customizing Audacity from the source code.

If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like

VS2017 RC

Permanent link to this post Posted by henric » Fri Nov 18, 2016 2:40 am

Only a few minor build changes were needed to get Audacity to compile with Visual Studio 2017 RC. A third wxWidgets directory was added to keep the includes, DLLs, and .lib files apart, with the WXWIN folders set to:
Code: Select all
WXWIN_VS2013={path to wxWidgets 3.0.2}
WXWIN_VS2015={path to wxWidgets 3.1}
WXWIN_VS2017={path to wxWidgets HEAD}

As before, if the WXWIN environment variable is set, then the WXWIN_* variables will be ignored by everything other than the "cd" commands in the build .bat files (in other words, builds should work fine from inside Visual Studio as long as one compile wxWidgets with the same compiler/SDK as one is using for Audacity). The VS2017 build should work with wxWidgets 3.1 as well, but that was not tested. Note that wxWidgets after 3.1 no longer requires the work-around for XP builds.

The VS2017 tools path environment variable was not set by the RC installer (should it?), so this was added to the system environment to get the VS2017 build scripts (build_wx2017.bat and build_2017.bat) to work:
Code: Select all
VS150COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\

The VS2017 command prompt sets the variable, so one could perhaps use that instead.

This brings the total number of separate builds up to 42:
Code: Select all
audacity_d_win32_2013.log   audacity_d_win32_2015.log   audacity_d_win32_2017.log   audacity_d_x64_2013.log
audacity_d_x64_2015.log     audacity_d_x64_2017.log     audacity_s_win32_2013.log   audacity_s_win32_2015.log
audacity_s_win32_2017.log   audacity_s_x64_2013.log     audacity_s_x64_2015.log     audacity_s_x64_2017.log
audacity_win32_2013.log     audacity_win32_2015.log     audacity_win32_2017.log     audacity_x64_2013.log
audacity_x64_2015.log       audacity_x64_2017.log       wxd_win32_2013.log          wxd_win32_2015.log
wxd_win32_2017.log          wxd_win32_dll_2013.log      wxd_win32_dll_2015.log      wxd_win32_dll_2017.log
wxd_x64_2013.log            wxd_x64_2015.log            wxd_x64_2017.log            wxd_x64_dll_2013.log
wxd_x64_dll_2015.log        wxd_x64_dll_2017.log        wx_win32_2013.log           wx_win32_2015.log
wx_win32_2017.log           wx_win32_dll_2013.log       wx_win32_dll_2015.log       wx_win32_dll_2017.log
wx_x64_2013.log             wx_x64_2015.log             wx_x64_2017.log             wx_x64_dll_2013.log
wx_x64_dll_2015.log         wx_x64_dll_2017.log

Since it has not been released, the VS 2017 builds were commented out in build_all.bat. Running build_all.bat, build_wx2017.bat, and build_2017.bat results in 18 different Audacity EXEs, but the most interesting EXEs for most people is probably the one in the "win\build\bin\v141\x64\Static Release" (64-bit build for Vista or later compiled by the VC++ in VS2017 and statically linked against the wxWidgets libraries).

Testing beyond verifying that the application starts and can run a simple effect and Nyquist script has not been done.

These x64, VS2015, and VS2017 changes are all on the fork's x64 branch (which is the default branch). The fork's master branch is the same as the official Audacity master.
henric
 
Posts: 31
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Return to Compiling Audacity



Who is online

Users browsing this forum: No registered users and 3 guests