AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Henric Jungheim-2

Due to space constraints, I've pulled VS2013 from my
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
x64:
   https://ci.appveyor.com/project/henricj/audacity

The GitHub source for the build is the x64 branch here:
   https://github.com/henricj/audacity
The submodule points here:
   https://github.com/henricj/wxWidgets/tree/audacity303

Outside AppVeyor, the code should build with the full Visual
Studio or with just the Build Tools.
   http://landinghub.visualstudio.com/visual-cpp-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?

Notes:

-- 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).


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

MartynShaw
I'm sorry Henric, I don't understand any of this.  Hopefully somebody else will.

TTFN
Martyn

On 15 June 2017 at 07:49, Henric Jungheim <[hidden email]> wrote:

Due to space constraints, I've pulled VS2013 from my
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
x64:
   https://ci.appveyor.com/project/henricj/audacity

The GitHub source for the build is the x64 branch here:
   https://github.com/henricj/audacity
The submodule points here:
   https://github.com/henricj/wxWidgets/tree/audacity303

Outside AppVeyor, the code should build with the full Visual
Studio or with just the Build Tools.
   http://landinghub.visualstudio.com/visual-cpp-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?

Notes:

-- 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).


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Henric Jungheim

The TL;DR, anti-TMI, or perhaps, "Executive Summary"
version: There are automatic Visual Studio builds of a fork
of the Audacity tree, with combinations of 32-bit and
64-bit, Visual Studio 2013 and 2017 (some may have VS2015
builds as well, depending on how I've configured things),
including ones optimized for the SSE2 (32-bit only), AVX, and
AVX2 instruction extensions under the "Artifacts" tab here:
   https://ci.appveyor.com/project/henricj/audacity
For example, this zip file contains an AVX-optimized, 64-bit
exe for Audacity built by Visual Studio 2017
   https://ci.appveyor.com/project/henricj/audacity/build/1.0.25/job/bty0se1xfge285cj/artifacts

There are some changes that might be of interest to the main
Audacity project--perhaps as they are; perhaps in modified
form.  There are are already some pending pull requests and
I thought I'd look at putting together a branch that has the
bare minimum changes required to get Audacity building on
versions of Visual Studio later than VS2013.  The pull
requests I submitted last April are not enough and some are
way, way out of date.  Anyhow, as I'm poking about this
stuff anyway, it seemes reasonable to try to do so in a way
that would be most useful to the Audacity project, and does
not needlessly duplicate other people's efforts.


Regarding those AppVeyor builds:

The builds are kicked off automatically whenever I push to
GitHub, so a given build might or might not even run.  Note
that if a computer doesn't support the AVX instructions,
then the app from the AVX build will crash on startup.  If
it does support those instructions, then some of the
math-heavy stuff is likely to run faster.  The Visual Studio
2017 redistributables--sort of like Microsoft's glibc--are
required for running those builds.  For the given example,
the x64 redist would be required.  They are not unlikely to
already be installed, but if the app complains about missing
DLLs, then expand the "Other Tools and Frameworks" at the
bottom of this page:
   https://www.visualstudio.com/downloads/
find "Microsoft Visual C++ Redistributable for Visual Studio
2017," and select the x64 or x86 version, as appropriate.

Only the 32-bit builds support XP since I figured that the
number of x64 Win XP installs was miniscule even when it was
a current OS, so there should hardly by any left at all by
now.



On Sat, Jun 17, 2017 at 12:34:18AM +0100, Martyn Shaw wrote:

>    I'm sorry Henric, I don't understand any of this.  Hopefully somebody
>    else will.
>    TTFN
>    Martyn
>
>    On 15 June 2017 at 07:49, Henric Jungheim <[1][hidden email]> wrote:
>
>      Due to space constraints, I've pulled VS2013 from my
>      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
>      x64:
>      Â  Â [2]https://ci.appveyor.com/project/henricj/audacity
>      The GitHub source for the build is the x64 branch here:
>      Â  Â [3]https://github.com/henricj/audacity
>      The submodule points here:
>      Â  Â [4]https://github.com/henricj/wxWidgets/tree/audacity303
>      Outside AppVeyor, the code should build with the full Visual
>      Studio or with just the Build Tools.
>      Â  Â [5]http://landinghub.visualstudio.com/visual-cpp-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?
>      Notes:
>      -- 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).
>      ------------------------------------------------------------
>      ------------------
>      Check out the vibrant tech community on one of the world's most
>      engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
>      _______________________________________________
>      audacity-devel mailing list
>      [7][hidden email]
>      [8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> References
>
>    1. mailto:[hidden email]
>    2. https://ci.appveyor.com/project/henricj/audacity
>    3. https://github.com/henricj/audacity
>    4. https://github.com/henricj/wxWidgets/tree/audacity303
>    5. http://landinghub.visualstudio.com/visual-cpp-build-tools
>    6. http://sdm.link/slashdot
>    7. mailto:[hidden email]
>    8. https://lists.sourceforge.net/lists/listinfo/audacity-devel

> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

David Bailes-3
In reply to this post by Henric Jungheim-2
On Thu, Jun 15, 2017 at 7:49 AM, Henric Jungheim <[hidden email]> wrote:

Due to space constraints, I've pulled VS2013 from my
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
x64:
   https://ci.appveyor.com/project/henricj/audacity

The GitHub source for the build is the x64 branch here:
   https://github.com/henricj/audacity
The submodule points here:
   https://github.com/henricj/wxWidgets/tree/audacity303

Outside AppVeyor, the code should build with the full Visual
Studio or with just the Build Tools.
   http://landinghub.visualstudio.com/visual-cpp-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?

Notes:

-- 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).

Just to give some feedback on using Visual studio 2017.

I've been looking at why Audacity was crashing when running Jaws on Windows 10 creator's update.
Using visual studio 2013 express when audacity crashed the debugger also hung, so I couldn't get a call stack.
I then built Audacity using visual studio 2017, using some of Henric's fixes, to check whether a newer compiler and windows sdk would fix the problem. It didn't, but the 2017 debugger doesn't hang when Audacity crashes (apart from the first time for some strange reason), so I can now get call stack. I haven't checked yet if I could still get a call stack if I used visual studio 2017 for the debugger but got it to use the 2013 compiler as Cliff is doing.

David.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Gale
Administrator
In reply to this post by Henric Jungheim
Hi Henric

VS versions apart, I expect a subset of users would greatly appreciate
a 64-bit build.

My computer does not support AVX so I could not try the build you
offered.


Gale


On 17 June 2017 at 08:12, Henric Jungheim <[hidden email]> wrote:

>
> The TL;DR, anti-TMI, or perhaps, "Executive Summary"
> version: There are automatic Visual Studio builds of a fork
> of the Audacity tree, with combinations of 32-bit and
> 64-bit, Visual Studio 2013 and 2017 (some may have VS2015
> builds as well, depending on how I've configured things),
> including ones optimized for the SSE2 (32-bit only), AVX, and
> AVX2 instruction extensions under the "Artifacts" tab here:
>    https://ci.appveyor.com/project/henricj/audacity
> For example, this zip file contains an AVX-optimized, 64-bit
> exe for Audacity built by Visual Studio 2017
>    https://ci.appveyor.com/project/henricj/audacity/build/1.0.25/job/bty0se1xfge285cj/artifacts
>
> There are some changes that might be of interest to the main
> Audacity project--perhaps as they are; perhaps in modified
> form.  There are are already some pending pull requests and
> I thought I'd look at putting together a branch that has the
> bare minimum changes required to get Audacity building on
> versions of Visual Studio later than VS2013.  The pull
> requests I submitted last April are not enough and some are
> way, way out of date.  Anyhow, as I'm poking about this
> stuff anyway, it seemes reasonable to try to do so in a way
> that would be most useful to the Audacity project, and does
> not needlessly duplicate other people's efforts.
>
>
> Regarding those AppVeyor builds:
>
> The builds are kicked off automatically whenever I push to
> GitHub, so a given build might or might not even run.  Note
> that if a computer doesn't support the AVX instructions,
> then the app from the AVX build will crash on startup.  If
> it does support those instructions, then some of the
> math-heavy stuff is likely to run faster.  The Visual Studio
> 2017 redistributables--sort of like Microsoft's glibc--are
> required for running those builds.  For the given example,
> the x64 redist would be required.  They are not unlikely to
> already be installed, but if the app complains about missing
> DLLs, then expand the "Other Tools and Frameworks" at the
> bottom of this page:
>    https://www.visualstudio.com/downloads/
> find "Microsoft Visual C++ Redistributable for Visual Studio
> 2017," and select the x64 or x86 version, as appropriate.
>
> Only the 32-bit builds support XP since I figured that the
> number of x64 Win XP installs was miniscule even when it was
> a current OS, so there should hardly by any left at all by
> now.
>
>
>
> On Sat, Jun 17, 2017 at 12:34:18AM +0100, Martyn Shaw wrote:
>>    I'm sorry Henric, I don't understand any of this.  Hopefully somebody
>>    else will.
>>    TTFN
>>    Martyn
>>
>>    On 15 June 2017 at 07:49, Henric Jungheim <[1][hidden email]> wrote:
>>
>>      Due to space constraints, I've pulled VS2013 from my
>>      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
>>      x64:
>>      Â  Â [2]https://ci.appveyor.com/project/henricj/audacity
>>      The GitHub source for the build is the x64 branch here:
>>      Â  Â [3]https://github.com/henricj/audacity
>>      The submodule points here:
>>      Â  Â [4]https://github.com/henricj/wxWidgets/tree/audacity303
>>      Outside AppVeyor, the code should build with the full Visual
>>      Studio or with just the Build Tools.
>>      Â  Â [5]http://landinghub.visualstudio.com/visual-cpp-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?
>>      Notes:
>>      -- 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).
>>      ------------------------------------------------------------
>>      ------------------
>>      Check out the vibrant tech community on one of the world's most
>>      engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
>>      _______________________________________________
>>      audacity-devel mailing list
>>      [7][hidden email]
>>      [8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> References
>>
>>    1. mailto:[hidden email]
>>    2. https://ci.appveyor.com/project/henricj/audacity
>>    3. https://github.com/henricj/audacity
>>    4. https://github.com/henricj/wxWidgets/tree/audacity303
>>    5. http://landinghub.visualstudio.com/visual-cpp-build-tools
>>    6. http://sdm.link/slashdot
>>    7. mailto:[hidden email]
>>    8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Henric Jungheim

If you go to the "JOBS" link on that page you should see all
the variations that AppVeyor built, including two 64-bit,
non-AVX builds (one by VS2017 and one by VS2013).  There is
no SSE or SSE2 build for 64-bit, since the 64-bit compiler
always assumes at least SSE2.


On Sat, Jun 17, 2017 at 03:23:16PM +0100, Gale Andrews wrote:

> Hi Henric
>
> VS versions apart, I expect a subset of users would greatly appreciate
> a 64-bit build.
>
> My computer does not support AVX so I could not try the build you
> offered.
>
>
> Gale
>
>
> On 17 June 2017 at 08:12, Henric Jungheim <[hidden email]> wrote:
> >
> > The TL;DR, anti-TMI, or perhaps, "Executive Summary"
> > version: There are automatic Visual Studio builds of a fork
> > of the Audacity tree, with combinations of 32-bit and
> > 64-bit, Visual Studio 2013 and 2017 (some may have VS2015
> > builds as well, depending on how I've configured things),
> > including ones optimized for the SSE2 (32-bit only), AVX, and
> > AVX2 instruction extensions under the "Artifacts" tab here:
> >    https://ci.appveyor.com/project/henricj/audacity
> > For example, this zip file contains an AVX-optimized, 64-bit
> > exe for Audacity built by Visual Studio 2017
> >    https://ci.appveyor.com/project/henricj/audacity/build/1.0.25/job/bty0se1xfge285cj/artifacts
> >
> > There are some changes that might be of interest to the main
> > Audacity project--perhaps as they are; perhaps in modified
> > form.  There are are already some pending pull requests and
> > I thought I'd look at putting together a branch that has the
> > bare minimum changes required to get Audacity building on
> > versions of Visual Studio later than VS2013.  The pull
> > requests I submitted last April are not enough and some are
> > way, way out of date.  Anyhow, as I'm poking about this
> > stuff anyway, it seemes reasonable to try to do so in a way
> > that would be most useful to the Audacity project, and does
> > not needlessly duplicate other people's efforts.
> >
> >
> > Regarding those AppVeyor builds:
> >
> > The builds are kicked off automatically whenever I push to
> > GitHub, so a given build might or might not even run.  Note
> > that if a computer doesn't support the AVX instructions,
> > then the app from the AVX build will crash on startup.  If
> > it does support those instructions, then some of the
> > math-heavy stuff is likely to run faster.  The Visual Studio
> > 2017 redistributables--sort of like Microsoft's glibc--are
> > required for running those builds.  For the given example,
> > the x64 redist would be required.  They are not unlikely to
> > already be installed, but if the app complains about missing
> > DLLs, then expand the "Other Tools and Frameworks" at the
> > bottom of this page:
> >    https://www.visualstudio.com/downloads/
> > find "Microsoft Visual C++ Redistributable for Visual Studio
> > 2017," and select the x64 or x86 version, as appropriate.
> >
> > Only the 32-bit builds support XP since I figured that the
> > number of x64 Win XP installs was miniscule even when it was
> > a current OS, so there should hardly by any left at all by
> > now.
> >
> >
> >
> > On Sat, Jun 17, 2017 at 12:34:18AM +0100, Martyn Shaw wrote:
> >>    I'm sorry Henric, I don't understand any of this.  Hopefully somebody
> >>    else will.
> >>    TTFN
> >>    Martyn
> >>
> >>    On 15 June 2017 at 07:49, Henric Jungheim <[1][hidden email]> wrote:
> >>
> >>      Due to space constraints, I've pulled VS2013 from my
> >>      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
> >>      x64:
> >>      Â  Â [2]https://ci.appveyor.com/project/henricj/audacity
> >>      The GitHub source for the build is the x64 branch here:
> >>      Â  Â [3]https://github.com/henricj/audacity
> >>      The submodule points here:
> >>      Â  Â [4]https://github.com/henricj/wxWidgets/tree/audacity303
> >>      Outside AppVeyor, the code should build with the full Visual
> >>      Studio or with just the Build Tools.
> >>      Â  Â [5]http://landinghub.visualstudio.com/visual-cpp-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?
> >>      Notes:
> >>      -- 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).
> >>      ------------------------------------------------------------
> >>      ------------------
> >>      Check out the vibrant tech community on one of the world's most
> >>      engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
> >>      _______________________________________________
> >>      audacity-devel mailing list
> >>      [7][hidden email]
> >>      [8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>
> >> References
> >>
> >>    1. mailto:[hidden email]
> >>    2. https://ci.appveyor.com/project/henricj/audacity
> >>    3. https://github.com/henricj/audacity
> >>    4. https://github.com/henricj/wxWidgets/tree/audacity303
> >>    5. http://landinghub.visualstudio.com/visual-cpp-build-tools
> >>    6. http://sdm.link/slashdot
> >>    7. mailto:[hidden email]
> >>    8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >> ------------------------------------------------------------------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >> _______________________________________________
> >> audacity-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Gale
Administrator
The links on https://ci.appveyor.com/project/henricj/audacity
just send you back to the Console output.

This looks hopeful but gives a server error:
https://ci.appveyor.com/project/henricj/audacity/build/job/9r526502p6q4uuee/artifacts
.

Sorry I don't have patience to puzzle it out. I am still interested in
trying a 64-bit non-AVX build by VS2017 if you have one.


Gale


On 17 June 2017 at 17:00, Henric Jungheim <[hidden email]> wrote:

>
> If you go to the "JOBS" link on that page you should see all
> the variations that AppVeyor built, including two 64-bit,
> non-AVX builds (one by VS2017 and one by VS2013).  There is
> no SSE or SSE2 build for 64-bit, since the 64-bit compiler
> always assumes at least SSE2.
>
>
> On Sat, Jun 17, 2017 at 03:23:16PM +0100, Gale Andrews wrote:
>> Hi Henric
>>
>> VS versions apart, I expect a subset of users would greatly appreciate
>> a 64-bit build.
>>
>> My computer does not support AVX so I could not try the build you
>> offered.
>>
>>
>> Gale
>>
>>
>> On 17 June 2017 at 08:12, Henric Jungheim <[hidden email]> wrote:
>> >
>> > The TL;DR, anti-TMI, or perhaps, "Executive Summary"
>> > version: There are automatic Visual Studio builds of a fork
>> > of the Audacity tree, with combinations of 32-bit and
>> > 64-bit, Visual Studio 2013 and 2017 (some may have VS2015
>> > builds as well, depending on how I've configured things),
>> > including ones optimized for the SSE2 (32-bit only), AVX, and
>> > AVX2 instruction extensions under the "Artifacts" tab here:
>> >    https://ci.appveyor.com/project/henricj/audacity
>> > For example, this zip file contains an AVX-optimized, 64-bit
>> > exe for Audacity built by Visual Studio 2017
>> >    https://ci.appveyor.com/project/henricj/audacity/build/1.0.25/job/bty0se1xfge285cj/artifacts
>> >
>> > There are some changes that might be of interest to the main
>> > Audacity project--perhaps as they are; perhaps in modified
>> > form.  There are are already some pending pull requests and
>> > I thought I'd look at putting together a branch that has the
>> > bare minimum changes required to get Audacity building on
>> > versions of Visual Studio later than VS2013.  The pull
>> > requests I submitted last April are not enough and some are
>> > way, way out of date.  Anyhow, as I'm poking about this
>> > stuff anyway, it seemes reasonable to try to do so in a way
>> > that would be most useful to the Audacity project, and does
>> > not needlessly duplicate other people's efforts.
>> >
>> >
>> > Regarding those AppVeyor builds:
>> >
>> > The builds are kicked off automatically whenever I push to
>> > GitHub, so a given build might or might not even run.  Note
>> > that if a computer doesn't support the AVX instructions,
>> > then the app from the AVX build will crash on startup.  If
>> > it does support those instructions, then some of the
>> > math-heavy stuff is likely to run faster.  The Visual Studio
>> > 2017 redistributables--sort of like Microsoft's glibc--are
>> > required for running those builds.  For the given example,
>> > the x64 redist would be required.  They are not unlikely to
>> > already be installed, but if the app complains about missing
>> > DLLs, then expand the "Other Tools and Frameworks" at the
>> > bottom of this page:
>> >    https://www.visualstudio.com/downloads/
>> > find "Microsoft Visual C++ Redistributable for Visual Studio
>> > 2017," and select the x64 or x86 version, as appropriate.
>> >
>> > Only the 32-bit builds support XP since I figured that the
>> > number of x64 Win XP installs was miniscule even when it was
>> > a current OS, so there should hardly by any left at all by
>> > now.
>> >
>> >
>> >
>> > On Sat, Jun 17, 2017 at 12:34:18AM +0100, Martyn Shaw wrote:
>> >>    I'm sorry Henric, I don't understand any of this.  Hopefully somebody
>> >>    else will.
>> >>    TTFN
>> >>    Martyn
>> >>
>> >>    On 15 June 2017 at 07:49, Henric Jungheim <[1][hidden email]> wrote:
>> >>
>> >>      Due to space constraints, I've pulled VS2013 from my
>> >>      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
>> >>      x64:
>> >>      Â  Â [2]https://ci.appveyor.com/project/henricj/audacity
>> >>      The GitHub source for the build is the x64 branch here:
>> >>      Â  Â [3]https://github.com/henricj/audacity
>> >>      The submodule points here:
>> >>      Â  Â [4]https://github.com/henricj/wxWidgets/tree/audacity303
>> >>      Outside AppVeyor, the code should build with the full Visual
>> >>      Studio or with just the Build Tools.
>> >>      Â  Â [5]http://landinghub.visualstudio.com/visual-cpp-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?
>> >>      Notes:
>> >>      -- 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).
>> >>      ------------------------------------------------------------
>> >>      ------------------
>> >>      Check out the vibrant tech community on one of the world's most
>> >>      engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
>> >>      _______________________________________________
>> >>      audacity-devel mailing list
>> >>      [7][hidden email]
>> >>      [8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >>
>> >> References
>> >>
>> >>    1. mailto:[hidden email]
>> >>    2. https://ci.appveyor.com/project/henricj/audacity
>> >>    3. https://github.com/henricj/audacity
>> >>    4. https://github.com/henricj/wxWidgets/tree/audacity303
>> >>    5. http://landinghub.visualstudio.com/visual-cpp-build-tools
>> >>    6. http://sdm.link/slashdot
>> >>    7. mailto:[hidden email]
>> >>    8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >
>> >> _______________________________________________
>> >> audacity-devel mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|

Re: AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP

Henric Jungheim

On Sat, Jun 17, 2017 at 07:25:52PM +0100, Gale Andrews wrote:
> The links on https://ci.appveyor.com/project/henricj/audacity
> just send you back to the Console output.

To the right of where it says "Console", there should other
tabs for "MESSAGES", "TESTS" and, "ARTIFACTS".  The zip
files live in the "ARTIFACTS" tab.  Unfortunately, I added
the build's "Architecture" environment variable to the zip
file's name and it leaves the un-expanded macro in the
filename when the variable is empty.  This seems to confuse
AppVeyor's URL logic; it sure isn't liking the "%" signs.  A
new build is running now that's rebased on top of 9b06f76
"Small TrackPanel fixes, including bug 1662, popup menu
crashes" and that has "none" instead of an empty string for
the "Architecture" variable.  The VS2017/"none" builds jobs
are done, but it is still working on the others.  Here's the
direct link to this 64-bit, VS2017 build:
   https://ci.appveyor.com/project/henricj/audacity/build/1.0.47/job/dtb4mk3n5l9qxmp0/artifacts
I verified I could download and run it (I had it generate a
noise track, play back part of it, and exit without
crashing).

These are all the jobs for the 1.0.47 build (the build
numbers here are based the default template that AppVeyor set
up when I created the project):
   https://ci.appveyor.com/project/henricj/audacity/build/1.0.47
>
> This looks hopeful but gives a server error:
> https://ci.appveyor.com/project/henricj/audacity/build/job/9r526502p6q4uuee/artifacts
> .

That was probably the %Architecture% in the filename.

>
> Sorry I don't have patience to puzzle it out. I am still interested in
> trying a 64-bit non-AVX build by VS2017 if you have one.

I just got this AppVeyor stuff set up... :)

>
>
> Gale
>
>
> On 17 June 2017 at 17:00, Henric Jungheim <[hidden email]> wrote:
> >
> > If you go to the "JOBS" link on that page you should see all
> > the variations that AppVeyor built, including two 64-bit,
> > non-AVX builds (one by VS2017 and one by VS2013).  There is
> > no SSE or SSE2 build for 64-bit, since the 64-bit compiler
> > always assumes at least SSE2.
> >
> >
> > On Sat, Jun 17, 2017 at 03:23:16PM +0100, Gale Andrews wrote:
> >> Hi Henric
> >>
> >> VS versions apart, I expect a subset of users would greatly appreciate
> >> a 64-bit build.
> >>
> >> My computer does not support AVX so I could not try the build you
> >> offered.
> >>
> >>
> >> Gale
> >>
> >>
> >> On 17 June 2017 at 08:12, Henric Jungheim <[hidden email]> wrote:
> >> >
> >> > The TL;DR, anti-TMI, or perhaps, "Executive Summary"
> >> > version: There are automatic Visual Studio builds of a fork
> >> > of the Audacity tree, with combinations of 32-bit and
> >> > 64-bit, Visual Studio 2013 and 2017 (some may have VS2015
> >> > builds as well, depending on how I've configured things),
> >> > including ones optimized for the SSE2 (32-bit only), AVX, and
> >> > AVX2 instruction extensions under the "Artifacts" tab here:
> >> >    https://ci.appveyor.com/project/henricj/audacity
> >> > For example, this zip file contains an AVX-optimized, 64-bit
> >> > exe for Audacity built by Visual Studio 2017
> >> >    https://ci.appveyor.com/project/henricj/audacity/build/1.0.25/job/bty0se1xfge285cj/artifacts
> >> >
> >> > There are some changes that might be of interest to the main
> >> > Audacity project--perhaps as they are; perhaps in modified
> >> > form.  There are are already some pending pull requests and
> >> > I thought I'd look at putting together a branch that has the
> >> > bare minimum changes required to get Audacity building on
> >> > versions of Visual Studio later than VS2013.  The pull
> >> > requests I submitted last April are not enough and some are
> >> > way, way out of date.  Anyhow, as I'm poking about this
> >> > stuff anyway, it seemes reasonable to try to do so in a way
> >> > that would be most useful to the Audacity project, and does
> >> > not needlessly duplicate other people's efforts.
> >> >
> >> >
> >> > Regarding those AppVeyor builds:
> >> >
> >> > The builds are kicked off automatically whenever I push to
> >> > GitHub, so a given build might or might not even run.  Note
> >> > that if a computer doesn't support the AVX instructions,
> >> > then the app from the AVX build will crash on startup.  If
> >> > it does support those instructions, then some of the
> >> > math-heavy stuff is likely to run faster.  The Visual Studio
> >> > 2017 redistributables--sort of like Microsoft's glibc--are
> >> > required for running those builds.  For the given example,
> >> > the x64 redist would be required.  They are not unlikely to
> >> > already be installed, but if the app complains about missing
> >> > DLLs, then expand the "Other Tools and Frameworks" at the
> >> > bottom of this page:
> >> >    https://www.visualstudio.com/downloads/
> >> > find "Microsoft Visual C++ Redistributable for Visual Studio
> >> > 2017," and select the x64 or x86 version, as appropriate.
> >> >
> >> > Only the 32-bit builds support XP since I figured that the
> >> > number of x64 Win XP installs was miniscule even when it was
> >> > a current OS, so there should hardly by any left at all by
> >> > now.
> >> >
> >> >
> >> >
> >> > On Sat, Jun 17, 2017 at 12:34:18AM +0100, Martyn Shaw wrote:
> >> >>    I'm sorry Henric, I don't understand any of this.  Hopefully somebody
> >> >>    else will.
> >> >>    TTFN
> >> >>    Martyn
> >> >>
> >> >>    On 15 June 2017 at 07:49, Henric Jungheim <[1][hidden email]> wrote:
> >> >>
> >> >>      Due to space constraints, I've pulled VS2013 from my
> >> >>      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
> >> >>      x64:
> >> >>      Â  Â [2]https://ci.appveyor.com/project/henricj/audacity
> >> >>      The GitHub source for the build is the x64 branch here:
> >> >>      Â  Â [3]https://github.com/henricj/audacity
> >> >>      The submodule points here:
> >> >>      Â  Â [4]https://github.com/henricj/wxWidgets/tree/audacity303
> >> >>      Outside AppVeyor, the code should build with the full Visual
> >> >>      Studio or with just the Build Tools.
> >> >>      Â  Â [5]http://landinghub.visualstudio.com/visual-cpp-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?
> >> >>      Notes:
> >> >>      -- 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).
> >> >>      ------------------------------------------------------------
> >> >>      ------------------
> >> >>      Check out the vibrant tech community on one of the world's most
> >> >>      engaging tech sites, Slashdot.org! [6]http://sdm.link/slashdot
> >> >>      _______________________________________________
> >> >>      audacity-devel mailing list
> >> >>      [7][hidden email]
> >> >>      [8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >> >>
> >> >> References
> >> >>
> >> >>    1. mailto:[hidden email]
> >> >>    2. https://ci.appveyor.com/project/henricj/audacity
> >> >>    3. https://github.com/henricj/audacity
> >> >>    4. https://github.com/henricj/wxWidgets/tree/audacity303
> >> >>    5. http://landinghub.visualstudio.com/visual-cpp-build-tools
> >> >>    6. http://sdm.link/slashdot
> >> >>    7. mailto:[hidden email]
> >> >>    8. https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >> >
> >> >> ------------------------------------------------------------------------------
> >> >> Check out the vibrant tech community on one of the world's most
> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> >
> >> >> _______________________________________________
> >> >> audacity-devel mailing list
> >> >> [hidden email]
> >> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >> >
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > _______________________________________________
> >> > audacity-devel mailing list
> >> > [hidden email]
> >> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>
> >> ------------------------------------------------------------------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> audacity-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel