Discussion:
AppVeyor Builds with VS2013, VS2015, VS2017 for x64 and Win32/XP
(too old to reply)
Henric Jungheim
2017-06-15 06:49:46 UTC
Permalink
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).
Martyn Shaw
2017-06-16 23:34:18 UTC
Permalink
I'm sorry Henric, I don't understand any of this. Hopefully somebody else
will.

TTFN
Martyn
Post by Henric Jungheim
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
https://ci.appveyor.com/project/henricj/audacity
https://github.com/henricj/audacity
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
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).
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Henric Jungheim
2017-06-17 07:12:43 UTC
Permalink
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.
I'm sorry Henric, I don't understand any of this. Hopefully somebody
else will.
TTFN
Martyn
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
  [2]https://ci.appveyor.com/project/henricj/audacity
  [3]https://github.com/henricj/audacity
  [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
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).
------------------------------------------------------------
------------------
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
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-06-17 14:23:16 UTC
Permalink
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
Post by 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
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.
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
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.
I'm sorry Henric, I don't understand any of this. Hopefully somebody
else will.
TTFN
Martyn
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
  [2]https://ci.appveyor.com/project/henricj/audacity
  [3]https://github.com/henricj/audacity
  [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
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).
------------------------------------------------------------
------------------
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
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Henric Jungheim
2017-06-17 16:00:04 UTC
Permalink
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.
Post by Gale Andrews
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
Post by 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
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.
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
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.
I'm sorry Henric, I don't understand any of this. Hopefully somebody
else will.
TTFN
Martyn
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
  [2]https://ci.appveyor.com/project/henricj/audacity
  [3]https://github.com/henricj/audacity
  [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
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).
------------------------------------------------------------
------------------
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
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-06-17 18:25:52 UTC
Permalink
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
Post by 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.
Post by Gale Andrews
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
Post by 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
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.
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
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.
I'm sorry Henric, I don't understand any of this. Hopefully somebody
else will.
TTFN
Martyn
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
  [2]https://ci.appveyor.com/project/henricj/audacity
  [3]https://github.com/henricj/audacity
  [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
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).
------------------------------------------------------------
------------------
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
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Henric Jungheim
2017-06-18 02:17:32 UTC
Permalink
Post by Gale Andrews
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
Post by Gale Andrews
https://ci.appveyor.com/project/henricj/audacity/build/job/9r526502p6q4uuee/artifacts
.
That was probably the %Architecture% in the filename.
Post by Gale Andrews
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... :)
Post by Gale Andrews
Gale
Post by 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.
Post by Gale Andrews
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
Post by 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
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.
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
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.
I'm sorry Henric, I don't understand any of this. Hopefully somebody
else will.
TTFN
Martyn
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
  [2]https://ci.appveyor.com/project/henricj/audacity
  [3]https://github.com/henricj/audacity
  [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
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).
------------------------------------------------------------
------------------
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
[8]https://lists.sourceforge.net/lists/listinfo/audacity-devel
References
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
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
David Bailes
2017-06-17 11:49:27 UTC
Permalink
Post by Henric Jungheim
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
https://ci.appveyor.com/project/henricj/audacity
https://github.com/henricj/audacity
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
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).
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.
Post by Henric Jungheim
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...