Discussion:
[Audacity-devel] Appveyor (was Re: Jaws Crashes (was: GetLinked()))
Martyn Shaw
2017-06-29 01:09:14 UTC
Permalink
Hi there

It looks like you have Appveyor mostly sussed.

Could it be used to replace the current 'nightly' builds? It looks like
it, but would possibly need a good web page for users to find the build
they are looking for.

I tried a couple of your builds, the VS2017 win32 one did run on my PC but
only after effort to find and install the Redistributable msvcp140.dll;
that (and similar) should be in the zips, I think, if the zips are to be
generally useful. We put the msvcpXXX.dll files in the installers (also
msvcrXXX.dlls, I don't know why)

If you can get the locale stuff can be put in the right place, it looks
like this can generate the same as the 'official' release zips.

So 'yes', I do think it should be set up for the official GitHub repro.
Could you work on that?

TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
Hi David,
as you may well already be aware, nightly builds are available on this
[1]http://gaclrecords.org.uk/win-nightly/
Currently, the last build was on 26 June. When the next build is
posted
there it will include fixes both for the closing crash, and opening
stereo files crash. At the moment I haven't been able to crash
Audacity
using the current build, but you might like to have a good try.
David.
On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
Do you have a list of the âknown issuesâ? You said earlier that you
crash when switching from stereo to mono?
Â
How about nightly builds? Where would I find the builds that have
the
opening/closing screen fix?
Â
Best,
David
Â
Â
Â
From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build
environment. If you don't want to do that, then it would be still very
useful if you could help to make sure that we know all the
circumstances in which Audacity crashes when Jaws is running.
Â
David.
Â
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Â
Result; Windows says its looking for a solution to the problem, none
is
found so I click the close button. Rinse and repeat.
Â
Are there any debug builds available that might be able to keep track
of breakpoints? I donât have a build environment setup, but would be
happy to run a debug build and try the same thing. Any builds with
error reporting built in so relevant information could be sent to
developers?
Â
Best,
David
Â
Â
From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
what would be very helpful would be to try and find all the situations
in which Audacity crashes when using Jaws and the creators update. I'm
aware of some, for example when opening a stereo file, but there may
be
some which I'm not aware of, and need fixing.
Â
thanks,
David.
Â
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.
Â
Is there something I can do to help narrow the ishâs down?
Â
Side note; how do you blind folk follow these threads efficiently when
the text is interspursed? How do you know which are the most recent
comments? Itâs not obvious to me whoâs comments are whoâs. Iâm using
Windows Live Mail... html...
Â
Best,
David
Â
<snip>
Gale Andrews
2017-06-29 01:21:53 UTC
Permalink
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks like it,
but would possibly need a good web page for users to find the build they are
looking for.
The aim is still to use FossHub to present "nightlies" I believe, wherever
they are built.


Gale
Post by Martyn Shaw
I tried a couple of your builds, the VS2017 win32 one did run on my PC but
only after effort to find and install the Redistributable msvcp140.dll; that
(and similar) should be in the zips, I think, if the zips are to be
generally useful. We put the msvcpXXX.dll files in the installers (also
msvcrXXX.dlls, I don't know why)
If you can get the locale stuff can be put in the right place, it looks like
this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub repro.
Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
Hi David,
as you may well already be aware, nightly builds are available on this
[1]http://gaclrecords.org.uk/win-nightly/
Currently, the last build was on 26 June. When the next build is
posted
there it will include fixes both for the closing crash, and opening
stereo files crash. At the moment I haven't been able to crash
Audacity
using the current build, but you might like to have a good try.
David.
On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
Do you have a list of the âknown issuesâ? You said earlier that you
crash when switching from stereo to mono?
Â
How about nightly builds? Where would I find the builds that have
the
opening/closing screen fix?
Â
Best,
David
Â
Â
Â
From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build
environment. If you don't want to do that, then it would be still very
useful if you could help to make sure that we know all the
circumstances in which Audacity crashes when Jaws is running.
Â
David.
Â
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Â
Result; Windows says its looking for a solution to the problem, none
is
found so I click the close button. Rinse and repeat.
Â
Are there any debug builds available that might be able to keep track
of breakpoints? I donât have a build environment setup, but would
be
happy to run a debug build and try the same thing. Any builds with
error reporting built in so relevant information could be sent to
developers?
Â
Best,
David
Â
Â
From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
what would be very helpful would be to try and find all the situations
in which Audacity crashes when using Jaws and the creators update. I'm
aware of some, for example when opening a stereo file, but there may
be
some which I'm not aware of, and need fixing.
Â
thanks,
David.
Â
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.
Â
Is there something I can do to help narrow the ishâs down?
Â
Side note; how do you blind folk follow these threads efficiently when
the text is interspursed? How do you know which are the most recent
comments? Itâs not obvious to me whoâs comments are whoâs. Iâm
using
Windows Live Mail... html...
Â
Best,
David
Â
<snip>
------------------------------------------------------------------------------
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
Martyn Shaw
2017-06-30 00:05:33 UTC
Permalink
Post by Gale Andrews
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks like
it,
Post by Martyn Shaw
but would possibly need a good web page for users to find the build they
are
Post by Martyn Shaw
looking for.
The aim is still to use FossHub to present "nightlies" I believe, wherever
they are built.
I think the aim was to get them off your server and onto something else; FH
is the obvious place, yes, but not the only possibility.

TTFN
Martyn
Post by Gale Andrews
Gale
Post by Martyn Shaw
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but
Post by Martyn Shaw
only after effort to find and install the Redistributable msvcp140.dll;
that
Post by Martyn Shaw
(and similar) should be in the zips, I think, if the zips are to be
generally useful. We put the msvcpXXX.dll files in the installers (also
msvcrXXX.dlls, I don't know why)
If you can get the locale stuff can be put in the right place, it looks
like
Post by Martyn Shaw
this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub repro.
Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
Post by Martyn Shaw
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
Hi David,
as you may well already be aware, nightly builds are available on this
[1]http://gaclrecords.org.uk/win-nightly/
Currently, the last build was on 26 June. When the next build is
posted
there it will include fixes both for the closing crash, and opening
stereo files crash. At the moment I haven't been able to crash
Audacity
using the current build, but you might like to have a good try.
David.
On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
Do you have a list of the âknown issuesâ? You said earlier that
you
Post by Martyn Shaw
crash when switching from stereo to mono?
Â
How about nightly builds? Where would I find the builds that have
the
opening/closing screen fix?
Â
Best,
David
Â
Â
Â
From: David Bailes
Sent: Tuesday, June 27, 2017 6:30 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
thanks, we are already have a fix for Audacity crashing on closing.
Unfortunately, to help with any debugging, you'd need a build
environment. If you don't want to do that, then it would be still very
useful if you could help to make sure that we know all the
circumstances in which Audacity crashes when Jaws is running.
Â
David.
Â
On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
1. Open Audacity.
2. Press alt+f4 to close Audacity.
Â
Result; Windows says its looking for a solution to the problem,
none
Post by Martyn Shaw
is
found so I click the close button. Rinse and repeat.
Â
Are there any debug builds available that might be able to keep
track
Post by Martyn Shaw
of breakpoints? I donât have a build environment setup, but would be
happy to run a debug build and try the same thing. Any builds
with
Post by Martyn Shaw
error reporting built in so relevant information could be sent to
developers?
Â
Best,
David
Â
Â
From: David Bailes
Sent: Monday, June 26, 2017 7:08 AM
To: Audacity Development
Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
Â
Hi David,
what would be very helpful would be to try and find all the situations
in which Audacity crashes when using Jaws and the creators update. I'm
aware of some, for example when opening a stereo file, but there
may
Post by Martyn Shaw
be
some which I'm not aware of, and need fixing.
Â
thanks,
David.
Â
On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
I was pushed Windows 10 CE (Wince?) and Iâm now experiencing the
crashes using Audacity 2.1.3 and JAWS 18 with the latest scriptset.
Â
Is there something I can do to help narrow the ishâs down?
Â
Side note; how do you blind folk follow these threads efficiently when
the text is interspursed? How do you know which are the most
recent
Post by Martyn Shaw
comments? Itâs not obvious to me whoâs comments are whoâs. Iâm
using
Windows Live Mail... html...
Â
Best,
David
Â
<snip>
------------------------------------------------------------
------------------
Post by Martyn Shaw
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-29 18:42:47 UTC
Permalink
There would have been 9 "nightly" builds yesterday had
AppVeyor been hooked up directly (counting the green Travis
checkmarks). AppVeyor has scheduled builds too, but I have
never played with that. Once built, one would normally push
the artifact(s) to some other place.

As for the redist situation... This is a bit more
complicated with VS2015 and later thanks to the UCRT.

https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

Win10 comes with the UCRT stuff. Systems back to Vista
should get them through Windows Update. XP needs to have
them installed. AFAIK, the safest solution is to run redist
exe from MS. One could perhaps include a web link to the
download location? ("Run this if you have problems starting
the exe.") In addition to the C++ DLL (which does depend on
the C runtime) and--IIRC--a small vcruntime DLL), this is
what would be needed to provide the UCRT runtime for the
.zip deployment method:

Directory of C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86

2017-06-23 20:16 <DIR> .
2017-06-23 20:16 <DIR> ..
2017-03-30 00:42 18,752 api-ms-win-core-console-l1-1-0.dll
2017-03-30 00:42 18,240 api-ms-win-core-datetime-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-debug-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-errorhandling-l1-1-0.dll
2017-03-30 00:43 21,824 api-ms-win-core-file-l1-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l1-2-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l2-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-handle-l1-1-0.dll
2017-03-30 00:45 18,240 api-ms-win-core-heap-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-interlocked-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-libraryloader-l1-1-0.dll
2017-03-30 00:46 20,792 api-ms-win-core-localization-l1-2-0.dll
2017-03-30 00:46 18,752 api-ms-win-core-memory-l1-1-0.dll
2017-03-30 00:46 18,240 api-ms-win-core-namedpipe-l1-1-0.dll
2017-03-30 00:47 19,264 api-ms-win-core-processenvironment-l1-1-0.dll
2017-03-30 00:47 20,288 api-ms-win-core-processthreads-l1-1-0.dll
2017-03-30 00:47 18,752 api-ms-win-core-processthreads-l1-1-1.dll
2017-03-30 00:48 17,728 api-ms-win-core-profile-l1-1-0.dll
2017-03-30 00:48 17,728 api-ms-win-core-rtlsupport-l1-1-0.dll
2017-03-30 00:48 18,240 api-ms-win-core-string-l1-1-0.dll
2017-03-30 00:49 20,288 api-ms-win-core-synch-l1-1-0.dll
2017-03-30 00:49 18,744 api-ms-win-core-synch-l1-2-0.dll
2017-03-30 00:49 19,264 api-ms-win-core-sysinfo-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-timezone-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-util-l1-1-0.dll
2017-03-30 00:50 19,264 api-ms-win-crt-conio-l1-1-0.dll
2017-03-30 00:51 22,336 api-ms-win-crt-convert-l1-1-0.dll
2017-03-30 00:51 18,752 api-ms-win-crt-environment-l1-1-0.dll
2017-03-30 00:51 20,288 api-ms-win-crt-filesystem-l1-1-0.dll
2017-03-30 00:51 19,264 api-ms-win-crt-heap-l1-1-0.dll
2017-03-30 00:52 18,752 api-ms-win-crt-locale-l1-1-0.dll
2017-03-30 00:52 28,984 api-ms-win-crt-math-l1-1-0.dll
2017-03-30 00:52 26,432 api-ms-win-crt-multibyte-l1-1-0.dll
2017-03-30 00:53 73,024 api-ms-win-crt-private-l1-1-0.dll
2017-03-30 00:53 19,264 api-ms-win-crt-process-l1-1-0.dll
2017-03-30 00:54 22,848 api-ms-win-crt-runtime-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-stdio-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-string-l1-1-0.dll
2017-03-30 00:55 20,800 api-ms-win-crt-time-l1-1-0.dll
2017-03-30 00:55 18,744 api-ms-win-crt-utility-l1-1-0.dll
2017-03-30 00:55 1,147,712 ucrtbase.dll
41 File(s) 1,995,552 bytes

I know MS really discourages it, but one might also consider
linking the zip-deployed Audacity with the static runtime
(building with /MT instead of /MD). Statically linking with
the wxWidgets libraries should result in a stand-alone EXE.
For an installer based deployment, there's an MSM that
should take care of the runtime (I'm not sure how the
current installer is generated, but AppVeyor does have the
WiX Toolkit installed).

Alternately: One could include the C++ runtime stuff and let
Windows Update take care of the UCRT for most people, giving
XP users the link to where they can download and and run the
vcredist exe (I think it's about 15MB).

Building the help sometimes takes forever and isn't under
source control anyway. Could one build a tarball under
Linux "every once in a while" and having the Windows build
just grab a copy of that instead? It is currently not in my
appveyor.yml.


I'd can put together a pull request for the appveyor.yml
change. I suspect that if the appveyor.yml I'm using was
checked in to the official Audacity tree and someone with
write privs logged in to AppVeyor site with their GitHub
credentials and pointed AppVeyor at Audacity's GitHub repo,
it would start doing CI builds. Both Travis and AppVeyor
status should then show up next to the commits:
https://github.com/audacity/audacity/commits/master
What would be the goals for a first go-round? If the point
is to check that Windows builds work, then what I have now
is already there. If the point is to produce binaries that
are easy for the end-user to test then it is a little more
complicated. Re-enabling the "help" build means
occasionally long build times and perhaps some spurious
build failures. The existing .yml has "locale" disabled due
to long build time. I left it that way for the master
builds (I have it enabled in my x64 builds, but it is set up
a little differently since the GetText.Tools NuGet package
is handled by the locale project itself rather than being
handled in the .yml).

If we want to do something like also having a "nightly"
style build that produces a zip deployment and an .exe/.msi
installer, I could look at that too, but that would take a
bit more time and needs a few questions answered (like how
to deal with the above UCRT issues, how Audacity should be
build--which compiler, with static or dynamic wxWidgets
libraries, etc). It seems not unreasonable to start with
something perhaps a little less ambitious.

The differences I have now look like this (IIRC, the only
critical bit is the change to the AUDACITY_ROOT environment
variable):

diff --git a/appveyor.yml b/appveyor.yml
index af2f169a3..d31d5c00e 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -5,9 +5,15 @@
#if you want to work on this, please talk with us on
# https://lists.sourceforge.net/lists/listinfo/audacity-devel
#build time is circa 50 mins.
-version: 2.1.2-{build}
+version: 2.1.3-{build}
+branches:
+ only:
+ - master
+image: Visual Studio 2013
shallow_clone: true # reduce traffic
install:
+ - 'echo #define REV_LONG "%APPVEYOR_REPO_COMMIT%" > src\RevisionIdent.h'
+ - 'echo #define REV_TIME "%APPVEYOR_REPO_COMMIT_TIMESTAMP%" >> src\RevisionIdent.h'
# install gettext tool (only used by target "locale", which is not built at
# the moment due to long duration
- nuget install Gettext.Tools
@@ -18,10 +24,10 @@ install:
- xcopy %AUDACITY_ROOT%\win\wxWidgets_additions\wxWidgets-3.0.2 %WXWIN% /s /y /f
- xcopy %WXWIN%\include\wx\setup_redirect.h %WXWIN%\include\wx\setup.h* /f
# build wxWidgets
- - msbuild %WXWIN%\build\msw\wx_vc12.sln /p:Configuration="DLL Release" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+ - msbuild /m %WXWIN%\build\msw\wx_vc12.sln "/p:Configuration=DLL Release;PlatformToolset=v120_xp" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
environment:
- WXWIN: c:\wxWidgets-3.0.2
- AUDACITY_ROOT: c:\projects\audacity
+ WXWIN: '%APPVEYOR_BUILD_FOLDER%\..\wxWidgets'
+ AUDACITY_ROOT: '%APPVEYOR_BUILD_FOLDER%'
# replace `build_script` with `build` and `configuration` when complete build
# does not exceed a duration of 1 hour
#build:
@@ -29,4 +35,14 @@ environment:
#configuration:
#- Release
build_script: # build all targets except of `help` and `locale`
- msbuild win/audacity.sln /p:Configuration=Release /target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,help,Audacity /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmd: >-
+ msbuild /m win/audacity.sln /p:Configuration=Release;PlatformToolset=v120_xp /target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,Audacity /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" &&
+ del /S win\Release\*.ipdb &
+ del /S win\Release\*.iobj &
+ del /S win\Release\*.lib &
+ del /S win\Release\*.pdb &
+ del /S win\Release\*.exp &
+ copy %WXWIN%\lib\vc_dll\*.dll win\Release\
+artifacts:
+- path: win\Release
+ name: 'audacity-%APPVEYOR_BUILD_VERSION%-%APPVEYOR_REPO_COMMIT%-%APPVEYOR_BUILD_WORKER_IMAGE%'
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks
like it, but would possibly need a good web page for users to find the
build they are looking for.
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but only after effort to find and install
the Redistributable msvcp140.dll; that (and similar) should be in the
zips, I think, if the zips are to be generally useful. We put the
msvcpXXX.dll files in the installers (also msvcrXXX.dlls, I don't know
why)
If you can get the locale stuff can be put in the right place, it looks
like this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub
repro. Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
  [2]https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
  [3]https://ci.appveyor.com/project/henricj/audacity/
build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
  Hi David,
  as you may well already be aware, nightly builds are
available on this
  [1][4]http://gaclrecords.org.uk/win-nightly/
  Currently, the last build was on 26 June. When the next build
is posted
  there it will include fixes both for the closing crash, and
opening
  stereo files crash. At the moment I haven't been able to
crash Audacity
  using the current build, but you might like to have a good
try.
  David.
  On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
  Do you have a list of the âknown issuesâ?àYou said
earlier that you
  crash when switching from stereo to mono?
  Ã
  How about nightly builds?àWhere would I find the builds
that have the
  opening/closing screen fix?
  Ã
  Best,
  David
  Ã
  Ã
  Ã
  From: David Bailes
  Sent: Tuesday, June 27, 2017 6:30 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  thanks, we are already have a fix for Audacity crashing on
closing.
  Unfortunately, to help with any debugging, you'd need a build
  environment. If you don't want to do that, then it would be
still very
  useful if you could help to make sure that we know all the
  circumstances in which Audacity crashes when Jaws is running.
  Ã
  David.
  Ã
  On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
  1. Open Audacity.
  2. Press alt+f4 to close Audacity.
  Ã
  Result; Windows says its looking for a solution to the
problem, none is
  found so I click the close button.àRinse and repeat.
  Ã
  Are there any debug builds available that might be able to
keep track
  of breakpoints?àI donât have a build environment setup,
but would be
  happy to run a debug build and try the same thing.àAny
builds with
  error reporting built in so relevant information could be
sent to
  developers?
  Ã
  Best,
  David
  Ã
  Ã
  From: David Bailes
  Sent: Monday, June 26, 2017 7:08 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  what would be very helpful would be to try and find all the
situations
  in which Audacity crashes when using Jaws and the creators
update. I'm
  aware of some, for example when opening a stereo file, but
there may be
  some which I'm not aware of, and need fixing.
  Ã
  thanks,
  David.
  Ã
  On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
  I was pushed Windows 10 CE (Wince?) and Iâm now experiencing
the
  crashes using Audacity 2.1.3 and JAWS 18 with the latest
scriptset.
  Ã
  Is there something I can do to help narrow the ishâs down?
  Ã
  Side note; how do you blind folk follow these threads
efficiently when
  the text is interspursed?àHow do you know which are the
most recent
  comments?àItâs not obvious to me whoâs comments are
whoâs. Iâm using
  Windows Live Mail... html...
  Ã
  Best,
  David
  Ã
Â
<snip>
References
2. https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
3. https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
4. http://gaclrecords.org.uk/win-nightly/
------------------------------------------------------------------------------
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-30 00:25:16 UTC
Permalink
The current view about the nightly builds produced now is that
they should have a complete set of locales but not necessarily
have help.


Gale
Post by Henric Jungheim
There would have been 9 "nightly" builds yesterday had
AppVeyor been hooked up directly (counting the green Travis
checkmarks). AppVeyor has scheduled builds too, but I have
never played with that. Once built, one would normally push
the artifact(s) to some other place.
As for the redist situation... This is a bit more
complicated with VS2015 and later thanks to the UCRT.
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Win10 comes with the UCRT stuff. Systems back to Vista
should get them through Windows Update. XP needs to have
them installed. AFAIK, the safest solution is to run redist
exe from MS. One could perhaps include a web link to the
download location? ("Run this if you have problems starting
the exe.") In addition to the C++ DLL (which does depend on
the C runtime) and--IIRC--a small vcruntime DLL), this is
what would be needed to provide the UCRT runtime for the
Directory of C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
2017-06-23 20:16 <DIR> .
2017-06-23 20:16 <DIR> ..
2017-03-30 00:42 18,752 api-ms-win-core-console-l1-1-0.dll
2017-03-30 00:42 18,240 api-ms-win-core-datetime-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-debug-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-errorhandling-l1-1-0.dll
2017-03-30 00:43 21,824 api-ms-win-core-file-l1-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l1-2-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l2-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-handle-l1-1-0.dll
2017-03-30 00:45 18,240 api-ms-win-core-heap-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-interlocked-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-libraryloader-l1-1-0.dll
2017-03-30 00:46 20,792 api-ms-win-core-localization-l1-2-0.dll
2017-03-30 00:46 18,752 api-ms-win-core-memory-l1-1-0.dll
2017-03-30 00:46 18,240 api-ms-win-core-namedpipe-l1-1-0.dll
2017-03-30 00:47 19,264 api-ms-win-core-processenvironment-l1-1-0.dll
2017-03-30 00:47 20,288 api-ms-win-core-processthreads-l1-1-0.dll
2017-03-30 00:47 18,752 api-ms-win-core-processthreads-l1-1-1.dll
2017-03-30 00:48 17,728 api-ms-win-core-profile-l1-1-0.dll
2017-03-30 00:48 17,728 api-ms-win-core-rtlsupport-l1-1-0.dll
2017-03-30 00:48 18,240 api-ms-win-core-string-l1-1-0.dll
2017-03-30 00:49 20,288 api-ms-win-core-synch-l1-1-0.dll
2017-03-30 00:49 18,744 api-ms-win-core-synch-l1-2-0.dll
2017-03-30 00:49 19,264 api-ms-win-core-sysinfo-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-timezone-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-util-l1-1-0.dll
2017-03-30 00:50 19,264 api-ms-win-crt-conio-l1-1-0.dll
2017-03-30 00:51 22,336 api-ms-win-crt-convert-l1-1-0.dll
2017-03-30 00:51 18,752 api-ms-win-crt-environment-l1-1-0.dll
2017-03-30 00:51 20,288 api-ms-win-crt-filesystem-l1-1-0.dll
2017-03-30 00:51 19,264 api-ms-win-crt-heap-l1-1-0.dll
2017-03-30 00:52 18,752 api-ms-win-crt-locale-l1-1-0.dll
2017-03-30 00:52 28,984 api-ms-win-crt-math-l1-1-0.dll
2017-03-30 00:52 26,432 api-ms-win-crt-multibyte-l1-1-0.dll
2017-03-30 00:53 73,024 api-ms-win-crt-private-l1-1-0.dll
2017-03-30 00:53 19,264 api-ms-win-crt-process-l1-1-0.dll
2017-03-30 00:54 22,848 api-ms-win-crt-runtime-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-stdio-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-string-l1-1-0.dll
2017-03-30 00:55 20,800 api-ms-win-crt-time-l1-1-0.dll
2017-03-30 00:55 18,744 api-ms-win-crt-utility-l1-1-0.dll
2017-03-30 00:55 1,147,712 ucrtbase.dll
41 File(s) 1,995,552 bytes
I know MS really discourages it, but one might also consider
linking the zip-deployed Audacity with the static runtime
(building with /MT instead of /MD). Statically linking with
the wxWidgets libraries should result in a stand-alone EXE.
For an installer based deployment, there's an MSM that
should take care of the runtime (I'm not sure how the
current installer is generated, but AppVeyor does have the
WiX Toolkit installed).
Alternately: One could include the C++ runtime stuff and let
Windows Update take care of the UCRT for most people, giving
XP users the link to where they can download and and run the
vcredist exe (I think it's about 15MB).
Building the help sometimes takes forever and isn't under
source control anyway. Could one build a tarball under
Linux "every once in a while" and having the Windows build
just grab a copy of that instead? It is currently not in my
appveyor.yml.
I'd can put together a pull request for the appveyor.yml
change. I suspect that if the appveyor.yml I'm using was
checked in to the official Audacity tree and someone with
write privs logged in to AppVeyor site with their GitHub
credentials and pointed AppVeyor at Audacity's GitHub repo,
it would start doing CI builds. Both Travis and AppVeyor
https://github.com/audacity/audacity/commits/master
What would be the goals for a first go-round? If the point
is to check that Windows builds work, then what I have now
is already there. If the point is to produce binaries that
are easy for the end-user to test then it is a little more
complicated. Re-enabling the "help" build means
occasionally long build times and perhaps some spurious
build failures. The existing .yml has "locale" disabled due
to long build time. I left it that way for the master
builds (I have it enabled in my x64 builds, but it is set up
a little differently since the GetText.Tools NuGet package
is handled by the locale project itself rather than being
handled in the .yml).
If we want to do something like also having a "nightly"
style build that produces a zip deployment and an .exe/.msi
installer, I could look at that too, but that would take a
bit more time and needs a few questions answered (like how
to deal with the above UCRT issues, how Audacity should be
build--which compiler, with static or dynamic wxWidgets
libraries, etc). It seems not unreasonable to start with
something perhaps a little less ambitious.
The differences I have now look like this (IIRC, the only
critical bit is the change to the AUDACITY_ROOT environment
diff --git a/appveyor.yml b/appveyor.yml
index af2f169a3..d31d5c00e 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -5,9 +5,15 @@
#if you want to work on this, please talk with us on
# https://lists.sourceforge.net/lists/listinfo/audacity-devel
#build time is circa 50 mins.
-version: 2.1.2-{build}
+version: 2.1.3-{build}
+ - master
+image: Visual Studio 2013
shallow_clone: true # reduce traffic
+ - 'echo #define REV_LONG "%APPVEYOR_REPO_COMMIT%" > src\RevisionIdent.h'
+ - 'echo #define REV_TIME "%APPVEYOR_REPO_COMMIT_TIMESTAMP%" >> src\RevisionIdent.h'
# install gettext tool (only used by target "locale", which is not built at
# the moment due to long duration
- nuget install Gettext.Tools
- xcopy %AUDACITY_ROOT%\win\wxWidgets_additions\wxWidgets-3.0.2 %WXWIN% /s /y /f
- xcopy %WXWIN%\include\wx\setup_redirect.h %WXWIN%\include\wx\setup.h* /f
# build wxWidgets
- - msbuild %WXWIN%\build\msw\wx_vc12.sln /p:Configuration="DLL Release" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+ - msbuild /m %WXWIN%\build\msw\wx_vc12.sln "/p:Configuration=DLL Release;PlatformToolset=v120_xp" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- WXWIN: c:\wxWidgets-3.0.2
- AUDACITY_ROOT: c:\projects\audacity
+ WXWIN: '%APPVEYOR_BUILD_FOLDER%\..\wxWidgets'
+ AUDACITY_ROOT: '%APPVEYOR_BUILD_FOLDER%'
# replace `build_script` with `build` and `configuration` when complete build
# does not exceed a duration of 1 hour
#- Release
build_script: # build all targets except of `help` and `locale`
- msbuild win/audacity.sln /p:Configuration=Release /target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,help,Audacity /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmd: >-
+ msbuild /m win/audacity.sln /p:Configuration=Release;PlatformToolset=v120_xp /target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,Audacity /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" &&
+ del /S win\Release\*.ipdb &
+ del /S win\Release\*.iobj &
+ del /S win\Release\*.lib &
+ del /S win\Release\*.pdb &
+ del /S win\Release\*.exp &
+ copy %WXWIN%\lib\vc_dll\*.dll win\Release\
+- path: win\Release
+ name: 'audacity-%APPVEYOR_BUILD_VERSION%-%APPVEYOR_REPO_COMMIT%-%APPVEYOR_BUILD_WORKER_IMAGE%'
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks
like it, but would possibly need a good web page for users to find the
build they are looking for.
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but only after effort to find and install
the Redistributable msvcp140.dll; that (and similar) should be in the
zips, I think, if the zips are to be generally useful. We put the
msvcpXXX.dll files in the installers (also msvcrXXX.dlls, I don't know
why)
If you can get the locale stuff can be put in the right place, it looks
like this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub
repro. Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
  [2]https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
  [3]https://ci.appveyor.com/project/henricj/audacity/
build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
  Hi David,
  as you may well already be aware, nightly builds are
available on this
  [1][4]http://gaclrecords.org.uk/win-nightly/
  Currently, the last build was on 26 June. When the next build
is posted
  there it will include fixes both for the closing crash, and
opening
  stereo files crash. At the moment I haven't been able to
crash Audacity
  using the current build, but you might like to have a good
try.
  David.
  On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
  Do you have a list of the âknown issuesâ?àYou said
earlier that you
  crash when switching from stereo to mono?
  Ã
  How about nightly builds?àWhere would I find the builds
that have the
  opening/closing screen fix?
  Ã
  Best,
  David
  Ã
  Ã
  Ã
  From: David Bailes
  Sent: Tuesday, June 27, 2017 6:30 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  thanks, we are already have a fix for Audacity crashing on
closing.
  Unfortunately, to help with any debugging, you'd need a build
  environment. If you don't want to do that, then it would be
still very
  useful if you could help to make sure that we know all the
  circumstances in which Audacity crashes when Jaws is running.
  Ã
  David.
  Ã
  On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
  1. Open Audacity.
  2. Press alt+f4 to close Audacity.
  Ã
  Result; Windows says its looking for a solution to the
problem, none is
  found so I click the close button.àRinse and repeat.
  Ã
  Are there any debug builds available that might be able to
keep track
  of breakpoints?àI donât have a build environment setup,
but would be
  happy to run a debug build and try the same thing.àAny
builds with
  error reporting built in so relevant information could be
sent to
  developers?
  Ã
  Best,
  David
  Ã
  Ã
  From: David Bailes
  Sent: Monday, June 26, 2017 7:08 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  what would be very helpful would be to try and find all the
situations
  in which Audacity crashes when using Jaws and the creators
update. I'm
  aware of some, for example when opening a stereo file, but
there may be
  some which I'm not aware of, and need fixing.
  Ã
  thanks,
  David.
  Ã
  On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
  I was pushed Windows 10 CE (Wince?) and Iâm now experiencing
the
  crashes using Audacity 2.1.3 and JAWS 18 with the latest
scriptset.
  Ã
  Is there something I can do to help narrow the ishâs down?
  Ã
  Side note; how do you blind folk follow these threads
efficiently when
  the text is interspursed?àHow do you know which are the
most recent
  comments?àItâs not obvious to me whoâs comments are
whoâs. Iâm using
  Windows Live Mail... html...
  Ã
  Best,
  David
  Ã
Â
<snip>
References
2. https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
3. https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
4. http://gaclrecords.org.uk/win-nightly/
------------------------------------------------------------------------------
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
Martyn Shaw
2017-06-30 00:49:28 UTC
Permalink
Hi there
Post by Henric Jungheim
There would have been 9 "nightly" builds yesterday had
AppVeyor been hooked up directly (counting the green Travis
checkmarks). AppVeyor has scheduled builds too, but I have
never played with that. Once built, one would normally push
the artifact(s) to some other place.
OK, that sounds good, maybe we can push them to FH, once they are fit for
purpose.

Why 9? I know very little about this, and Travis. Others may like to
chime in. This seems like a useful thing, automating builds.
Post by Henric Jungheim
As for the redist situation... This is a bit more
complicated with VS2015 and later thanks to the UCRT.
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/
introducing-the-universal-crt/
TLDR, I assume that you have knowledge about these things that I don't.
Post by Henric Jungheim
Win10 comes with the UCRT stuff. Systems back to Vista
should get them through Windows Update. XP needs to have
them installed.
I'm pretty sure that we / Audacity has long since stopped support for
Vista, and I think XP as well. That may simplify things.
Post by Henric Jungheim
AFAIK, the safest solution is to run redist
exe from MS. One could perhaps include a web link to the
download location? ("Run this if you have problems starting
the exe.")
We would like to make it as easy as possible for a.n.interestedParty to try
a 'nightly build' or a 'current build', and if it meant them going off
looking for other stuff, that would be a pain for them. My experience of
getting a suitable dll was not great (but worked), and I have some software
knowledge. Convincing Audacity folk that using VS 2015 or 2017 may be a
motivation here for you. Hopefully that wouldn't shut out other devs.

We have to think about 'musician x' who plays guitar and keys and wants to
try the latest Audacity thingy that she has heard about on some social
media. She knows what computer she has, clicks on an appropriate link,
unzips and is ready to go, and then gives us feedback on how great (or
otherwise) the thingy was. OK, that would be ideal, how far can we go
towards that? Otherwise it's just for us geeks, which is OK as well.

Our traditional Win release process is detailed at

http://wiki.audacityteam.org/wiki/Release_Process/Win

you may like to review / comment on that. We don't have 'help' in the zip,
and for 'nightlies' or 'current build's we wouldn't need them either. I'm
not sure about 'locale'.

TTFN
Martyn


In addition to the C++ DLL (which does depend on
Post by Henric Jungheim
the C runtime) and--IIRC--a small vcruntime DLL), this is
what would be needed to provide the UCRT runtime for the
Directory of C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
2017-06-23 20:16 <DIR> .
2017-06-23 20:16 <DIR> ..
2017-03-30 00:42 18,752 api-ms-win-core-console-l1-1-0.dll
2017-03-30 00:42 18,240 api-ms-win-core-datetime-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-debug-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-errorhandling-
l1-1-0.dll
2017-03-30 00:43 21,824 api-ms-win-core-file-l1-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l1-2-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l2-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-handle-l1-1-0.dll
2017-03-30 00:45 18,240 api-ms-win-core-heap-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-interlocked-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-libraryloader-
l1-1-0.dll
2017-03-30 00:46 20,792 api-ms-win-core-localization-
l1-2-0.dll
2017-03-30 00:46 18,752 api-ms-win-core-memory-l1-1-0.dll
2017-03-30 00:46 18,240 api-ms-win-core-namedpipe-l1-1-0.dll
2017-03-30 00:47 19,264 api-ms-win-core-
processenvironment-l1-1-0.dll
2017-03-30 00:47 20,288 api-ms-win-core-
processthreads-l1-1-0.dll
2017-03-30 00:47 18,752 api-ms-win-core-
processthreads-l1-1-1.dll
2017-03-30 00:48 17,728 api-ms-win-core-profile-l1-1-0.dll
2017-03-30 00:48 17,728 api-ms-win-core-rtlsupport-l1-1-0.dll
2017-03-30 00:48 18,240 api-ms-win-core-string-l1-1-0.dll
2017-03-30 00:49 20,288 api-ms-win-core-synch-l1-1-0.dll
2017-03-30 00:49 18,744 api-ms-win-core-synch-l1-2-0.dll
2017-03-30 00:49 19,264 api-ms-win-core-sysinfo-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-timezone-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-util-l1-1-0.dll
2017-03-30 00:50 19,264 api-ms-win-crt-conio-l1-1-0.dll
2017-03-30 00:51 22,336 api-ms-win-crt-convert-l1-1-0.dll
2017-03-30 00:51 18,752 api-ms-win-crt-environment-l1-1-0.dll
2017-03-30 00:51 20,288 api-ms-win-crt-filesystem-l1-1-0.dll
2017-03-30 00:51 19,264 api-ms-win-crt-heap-l1-1-0.dll
2017-03-30 00:52 18,752 api-ms-win-crt-locale-l1-1-0.dll
2017-03-30 00:52 28,984 api-ms-win-crt-math-l1-1-0.dll
2017-03-30 00:52 26,432 api-ms-win-crt-multibyte-l1-1-0.dll
2017-03-30 00:53 73,024 api-ms-win-crt-private-l1-1-0.dll
2017-03-30 00:53 19,264 api-ms-win-crt-process-l1-1-0.dll
2017-03-30 00:54 22,848 api-ms-win-crt-runtime-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-stdio-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-string-l1-1-0.dll
2017-03-30 00:55 20,800 api-ms-win-crt-time-l1-1-0.dll
2017-03-30 00:55 18,744 api-ms-win-crt-utility-l1-1-0.dll
2017-03-30 00:55 1,147,712 ucrtbase.dll
41 File(s) 1,995,552 bytes
I know MS really discourages it, but one might also consider
linking the zip-deployed Audacity with the static runtime
(building with /MT instead of /MD). Statically linking with
the wxWidgets libraries should result in a stand-alone EXE.
For an installer based deployment, there's an MSM that
should take care of the runtime (I'm not sure how the
current installer is generated, but AppVeyor does have the
WiX Toolkit installed).
Alternately: One could include the C++ runtime stuff and let
Windows Update take care of the UCRT for most people, giving
XP users the link to where they can download and and run the
vcredist exe (I think it's about 15MB).
Building the help sometimes takes forever and isn't under
source control anyway. Could one build a tarball under
Linux "every once in a while" and having the Windows build
just grab a copy of that instead? It is currently not in my
appveyor.yml.
I'd can put together a pull request for the appveyor.yml
change. I suspect that if the appveyor.yml I'm using was
checked in to the official Audacity tree and someone with
write privs logged in to AppVeyor site with their GitHub
credentials and pointed AppVeyor at Audacity's GitHub repo,
it would start doing CI builds. Both Travis and AppVeyor
https://github.com/audacity/audacity/commits/master
What would be the goals for a first go-round? If the point
is to check that Windows builds work, then what I have now
is already there. If the point is to produce binaries that
are easy for the end-user to test then it is a little more
complicated. Re-enabling the "help" build means
occasionally long build times and perhaps some spurious
build failures. The existing .yml has "locale" disabled due
to long build time. I left it that way for the master
builds (I have it enabled in my x64 builds, but it is set up
a little differently since the GetText.Tools NuGet package
is handled by the locale project itself rather than being
handled in the .yml).
If we want to do something like also having a "nightly"
style build that produces a zip deployment and an .exe/.msi
installer, I could look at that too, but that would take a
bit more time and needs a few questions answered (like how
to deal with the above UCRT issues, how Audacity should be
build--which compiler, with static or dynamic wxWidgets
libraries, etc). It seems not unreasonable to start with
something perhaps a little less ambitious.
The differences I have now look like this (IIRC, the only
critical bit is the change to the AUDACITY_ROOT environment
diff --git a/appveyor.yml b/appveyor.yml
index af2f169a3..d31d5c00e 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -5,9 +5,15 @@
#if you want to work on this, please talk with us on
# https://lists.sourceforge.net/lists/listinfo/audacity-devel
#build time is circa 50 mins.
-version: 2.1.2-{build}
+version: 2.1.3-{build}
+ - master
+image: Visual Studio 2013
shallow_clone: true # reduce traffic
+ - 'echo #define REV_LONG "%APPVEYOR_REPO_COMMIT%" >
src\RevisionIdent.h'
+ - 'echo #define REV_TIME "%APPVEYOR_REPO_COMMIT_TIMESTAMP%" >> src\RevisionIdent.h'
# install gettext tool (only used by target "locale", which is not built at
# the moment due to long duration
- nuget install Gettext.Tools
- xcopy %AUDACITY_ROOT%\win\wxWidgets_additions\wxWidgets-3.0.2 %WXWIN% /s /y /f
- xcopy %WXWIN%\include\wx\setup_redirect.h
%WXWIN%\include\wx\setup.h* /f
# build wxWidgets
- - msbuild %WXWIN%\build\msw\wx_vc12.sln /p:Configuration="DLL
Release" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+ - msbuild /m %WXWIN%\build\msw\wx_vc12.sln "/p:Configuration=DLL
Release;PlatformToolset=v120_xp" /target:adv,base,core,html,
net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program
Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- WXWIN: c:\wxWidgets-3.0.2
- AUDACITY_ROOT: c:\projects\audacity
+ WXWIN: '%APPVEYOR_BUILD_FOLDER%\..\wxWidgets'
+ AUDACITY_ROOT: '%APPVEYOR_BUILD_FOLDER%'
# replace `build_script` with `build` and `configuration` when complete build
# does not exceed a duration of 1 hour
#- Release
build_script: # build all targets except of `help` and `locale`
- msbuild win/audacity.sln /p:Configuration=Release
/target:expat,filedialog,libflac++,libflac,libid3tag,
libmad,libnyquist,libogg,libscorealign,libsndfile,
libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,
portmixer,portsmf,sbsms,soundtouch,twolame,help,Audacity
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmd: >-
+ msbuild /m win/audacity.sln /p:Configuration=Release;PlatformToolset=v120_xp
/target:expat,filedialog,libflac++,libflac,libid3tag,
libmad,libnyquist,libogg,libscorealign,libsndfile,
libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,
portmixer,portsmf,sbsms,soundtouch,twolame,Audacity /logger:"C:\Program
Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" &&
+ del /S win\Release\*.ipdb &
+ del /S win\Release\*.iobj &
+ del /S win\Release\*.lib &
+ del /S win\Release\*.pdb &
+ del /S win\Release\*.exp &
+ copy %WXWIN%\lib\vc_dll\*.dll win\Release\
+- path: win\Release
+ name: 'audacity-%APPVEYOR_BUILD_VERSION%-%APPVEYOR_REPO_
COMMIT%-%APPVEYOR_BUILD_WORKER_IMAGE%'
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks
like it, but would possibly need a good web page for users to find the
build they are looking for.
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but only after effort to find and install
the Redistributable msvcp140.dll; that (and similar) should be in
the
Post by Martyn Shaw
zips, I think, if the zips are to be generally useful. We put the
msvcpXXX.dll files in the installers (also msvcrXXX.dlls, I don't know
why)
If you can get the locale stuff can be put in the right place, it
looks
Post by Martyn Shaw
like this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub
repro. Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
  [2]https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
  [3]https://ci.appveyor.com/project/henricj/audacity/
build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
  Hi David,
  as you may well already be aware, nightly builds are
available on this
  [1][4]http://gaclrecords.org.uk/win-nightly/
  Currently, the last build was on 26 June. When the next build
is posted
  there it will include fixes both for the closing crash, and
opening
  stereo files crash. At the moment I haven't been able to
crash Audacity
  using the current build, but you might like to have a good
try.
  David.
  On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
  Do you have a list of the âknown issuesâ?àYou said
earlier that you
  crash when switching from stereo to mono?
  Ã
  How about nightly builds?àWhere would I find the builds
that have the
  opening/closing screen fix?
  Ã
  Best,
  David
  Ã
  Ã
  Ã
  From: David Bailes
  Sent: Tuesday, June 27, 2017 6:30 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  thanks, we are already have a fix for Audacity crashing on
closing.
  Unfortunately, to help with any debugging, you'd need a build
  environment. If you don't want to do that, then it would be
still very
  useful if you could help to make sure that we know all the
  circumstances in which Audacity crashes when Jaws is running.
  Ã
  David.
  Ã
  On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
  1. Open Audacity.
  2. Press alt+f4 to close Audacity.
  Ã
  Result; Windows says its looking for a solution to the
problem, none is
  found so I click the close button.àRinse and repeat.
  Ã
  Are there any debug builds available that might be able to
keep track
  of breakpoints?àI donât have a build environment setup,
but would be
  happy to run a debug build and try the same thing.àAny
builds with
  error reporting built in so relevant information could be
sent to
  developers?
  Ã
  Best,
  David
  Ã
  Ã
  From: David Bailes
  Sent: Monday, June 26, 2017 7:08 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  what would be very helpful would be to try and find all the
situations
  in which Audacity crashes when using Jaws and the creators
update. I'm
  aware of some, for example when opening a stereo file, but
there may be
  some which I'm not aware of, and need fixing.
  Ã
  thanks,
  David.
  Ã
  On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
  I was pushed Windows 10 CE (Wince?) and Iâm now experiencing
the
  crashes using Audacity 2.1.3 and JAWS 18 with the latest
scriptset.
  Ã
  Is there something I can do to help narrow the ishâs down?
  Ã
  Side note; how do you blind folk follow these threads
efficiently when
  the text is interspursed?àHow do you know which are the
most recent
  comments?àItâs not obvious to me whoâs comments are
whoâs. Iâm using
  Windows Live Mail... html...
  Ã
  Best,
  David
  Ã
Â
<snip>
References
2. https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
Post by Martyn Shaw
3. https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
4. http://gaclrecords.org.uk/win-nightly/
------------------------------------------------------------
------------------
Post by Martyn Shaw
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-30 14:36:41 UTC
Permalink
Post by Martyn Shaw
Hi there
Post by Henric Jungheim
There would have been 9 "nightly" builds yesterday had
AppVeyor been hooked up directly (counting the green Travis
checkmarks). AppVeyor has scheduled builds too, but I have
never played with that. Once built, one would normally push
the artifact(s) to some other place.
OK, that sounds good, maybe we can push them to FH, once they are fit for
purpose.
Why 9? I know very little about this, and Travis. Others may like to chime
in. This seems like a useful thing, automating builds.
Post by Henric Jungheim
As for the redist situation... This is a bit more
complicated with VS2015 and later thanks to the UCRT.
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
TLDR, I assume that you have knowledge about these things that I don't.
Post by Henric Jungheim
Win10 comes with the UCRT stuff. Systems back to Vista
should get them through Windows Update. XP needs to have
them installed.
I'm pretty sure that we / Audacity has long since stopped support for Vista,
and I think XP as well. That may simplify things.
Vista is still supported. XP support ends with the release of 2.2.0.


Gale
Post by Martyn Shaw
Post by Henric Jungheim
AFAIK, the safest solution is to run redist
exe from MS. One could perhaps include a web link to the
download location? ("Run this if you have problems starting
the exe.")
We would like to make it as easy as possible for a.n.interestedParty to try
a 'nightly build' or a 'current build', and if it meant them going off
looking for other stuff, that would be a pain for them. My experience of
getting a suitable dll was not great (but worked), and I have some software
knowledge. Convincing Audacity folk that using VS 2015 or 2017 may be a
motivation here for you. Hopefully that wouldn't shut out other devs.
We have to think about 'musician x' who plays guitar and keys and wants to
try the latest Audacity thingy that she has heard about on some social
media. She knows what computer she has, clicks on an appropriate link,
unzips and is ready to go, and then gives us feedback on how great (or
otherwise) the thingy was. OK, that would be ideal, how far can we go
towards that? Otherwise it's just for us geeks, which is OK as well.
Our traditional Win release process is detailed at
http://wiki.audacityteam.org/wiki/Release_Process/Win
you may like to review / comment on that. We don't have 'help' in the zip,
and for 'nightlies' or 'current build's we wouldn't need them either. I'm
not sure about 'locale'.
TTFN
Martyn
Post by Henric Jungheim
In addition to the C++ DLL (which does depend on
the C runtime) and--IIRC--a small vcruntime DLL), this is
what would be needed to provide the UCRT runtime for the
Directory of C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
2017-06-23 20:16 <DIR> .
2017-06-23 20:16 <DIR> ..
2017-03-30 00:42 18,752 api-ms-win-core-console-l1-1-0.dll
2017-03-30 00:42 18,240 api-ms-win-core-datetime-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-debug-l1-1-0.dll
2017-03-30 00:43 18,240
api-ms-win-core-errorhandling-l1-1-0.dll
2017-03-30 00:43 21,824 api-ms-win-core-file-l1-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l1-2-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l2-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-handle-l1-1-0.dll
2017-03-30 00:45 18,240 api-ms-win-core-heap-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-interlocked-l1-1-0.dll
2017-03-30 00:45 18,752
api-ms-win-core-libraryloader-l1-1-0.dll
2017-03-30 00:46 20,792
api-ms-win-core-localization-l1-2-0.dll
2017-03-30 00:46 18,752 api-ms-win-core-memory-l1-1-0.dll
2017-03-30 00:46 18,240 api-ms-win-core-namedpipe-l1-1-0.dll
2017-03-30 00:47 19,264
api-ms-win-core-processenvironment-l1-1-0.dll
2017-03-30 00:47 20,288
api-ms-win-core-processthreads-l1-1-0.dll
2017-03-30 00:47 18,752
api-ms-win-core-processthreads-l1-1-1.dll
2017-03-30 00:48 17,728 api-ms-win-core-profile-l1-1-0.dll
2017-03-30 00:48 17,728 api-ms-win-core-rtlsupport-l1-1-0.dll
2017-03-30 00:48 18,240 api-ms-win-core-string-l1-1-0.dll
2017-03-30 00:49 20,288 api-ms-win-core-synch-l1-1-0.dll
2017-03-30 00:49 18,744 api-ms-win-core-synch-l1-2-0.dll
2017-03-30 00:49 19,264 api-ms-win-core-sysinfo-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-timezone-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-util-l1-1-0.dll
2017-03-30 00:50 19,264 api-ms-win-crt-conio-l1-1-0.dll
2017-03-30 00:51 22,336 api-ms-win-crt-convert-l1-1-0.dll
2017-03-30 00:51 18,752 api-ms-win-crt-environment-l1-1-0.dll
2017-03-30 00:51 20,288 api-ms-win-crt-filesystem-l1-1-0.dll
2017-03-30 00:51 19,264 api-ms-win-crt-heap-l1-1-0.dll
2017-03-30 00:52 18,752 api-ms-win-crt-locale-l1-1-0.dll
2017-03-30 00:52 28,984 api-ms-win-crt-math-l1-1-0.dll
2017-03-30 00:52 26,432 api-ms-win-crt-multibyte-l1-1-0.dll
2017-03-30 00:53 73,024 api-ms-win-crt-private-l1-1-0.dll
2017-03-30 00:53 19,264 api-ms-win-crt-process-l1-1-0.dll
2017-03-30 00:54 22,848 api-ms-win-crt-runtime-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-stdio-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-string-l1-1-0.dll
2017-03-30 00:55 20,800 api-ms-win-crt-time-l1-1-0.dll
2017-03-30 00:55 18,744 api-ms-win-crt-utility-l1-1-0.dll
2017-03-30 00:55 1,147,712 ucrtbase.dll
41 File(s) 1,995,552 bytes
I know MS really discourages it, but one might also consider
linking the zip-deployed Audacity with the static runtime
(building with /MT instead of /MD). Statically linking with
the wxWidgets libraries should result in a stand-alone EXE.
For an installer based deployment, there's an MSM that
should take care of the runtime (I'm not sure how the
current installer is generated, but AppVeyor does have the
WiX Toolkit installed).
Alternately: One could include the C++ runtime stuff and let
Windows Update take care of the UCRT for most people, giving
XP users the link to where they can download and and run the
vcredist exe (I think it's about 15MB).
Building the help sometimes takes forever and isn't under
source control anyway. Could one build a tarball under
Linux "every once in a while" and having the Windows build
just grab a copy of that instead? It is currently not in my
appveyor.yml.
I'd can put together a pull request for the appveyor.yml
change. I suspect that if the appveyor.yml I'm using was
checked in to the official Audacity tree and someone with
write privs logged in to AppVeyor site with their GitHub
credentials and pointed AppVeyor at Audacity's GitHub repo,
it would start doing CI builds. Both Travis and AppVeyor
https://github.com/audacity/audacity/commits/master
What would be the goals for a first go-round? If the point
is to check that Windows builds work, then what I have now
is already there. If the point is to produce binaries that
are easy for the end-user to test then it is a little more
complicated. Re-enabling the "help" build means
occasionally long build times and perhaps some spurious
build failures. The existing .yml has "locale" disabled due
to long build time. I left it that way for the master
builds (I have it enabled in my x64 builds, but it is set up
a little differently since the GetText.Tools NuGet package
is handled by the locale project itself rather than being
handled in the .yml).
If we want to do something like also having a "nightly"
style build that produces a zip deployment and an .exe/.msi
installer, I could look at that too, but that would take a
bit more time and needs a few questions answered (like how
to deal with the above UCRT issues, how Audacity should be
build--which compiler, with static or dynamic wxWidgets
libraries, etc). It seems not unreasonable to start with
something perhaps a little less ambitious.
The differences I have now look like this (IIRC, the only
critical bit is the change to the AUDACITY_ROOT environment
diff --git a/appveyor.yml b/appveyor.yml
index af2f169a3..d31d5c00e 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -5,9 +5,15 @@
#if you want to work on this, please talk with us on
# https://lists.sourceforge.net/lists/listinfo/audacity-devel
#build time is circa 50 mins.
-version: 2.1.2-{build}
+version: 2.1.3-{build}
+ - master
+image: Visual Studio 2013
shallow_clone: true # reduce traffic
+ - 'echo #define REV_LONG "%APPVEYOR_REPO_COMMIT%" >
src\RevisionIdent.h'
+ - 'echo #define REV_TIME "%APPVEYOR_REPO_COMMIT_TIMESTAMP%" >> src\RevisionIdent.h'
# install gettext tool (only used by target "locale", which is not built at
# the moment due to long duration
- nuget install Gettext.Tools
- xcopy %AUDACITY_ROOT%\win\wxWidgets_additions\wxWidgets-3.0.2 %WXWIN% /s /y /f
- xcopy %WXWIN%\include\wx\setup_redirect.h
%WXWIN%\include\wx\setup.h* /f
# build wxWidgets
- - msbuild %WXWIN%\build\msw\wx_vc12.sln /p:Configuration="DLL
Release"
/target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+ - msbuild /m %WXWIN%\build\msw\wx_vc12.sln "/p:Configuration=DLL
Release;PlatformToolset=v120_xp"
/target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- WXWIN: c:\wxWidgets-3.0.2
- AUDACITY_ROOT: c:\projects\audacity
+ WXWIN: '%APPVEYOR_BUILD_FOLDER%\..\wxWidgets'
+ AUDACITY_ROOT: '%APPVEYOR_BUILD_FOLDER%'
# replace `build_script` with `build` and `configuration` when complete build
# does not exceed a duration of 1 hour
#- Release
build_script: # build all targets except of `help` and `locale`
- msbuild win/audacity.sln /p:Configuration=Release
/target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,help,Audacity
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmd: >-
+ msbuild /m win/audacity.sln
/p:Configuration=Release;PlatformToolset=v120_xp
/target:expat,filedialog,libflac++,libflac,libid3tag,libmad,libnyquist,libogg,libscorealign,libsndfile,libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,portmixer,portsmf,sbsms,soundtouch,twolame,Audacity
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" &&
+ del /S win\Release\*.ipdb &
+ del /S win\Release\*.iobj &
+ del /S win\Release\*.lib &
+ del /S win\Release\*.pdb &
+ del /S win\Release\*.exp &
+ copy %WXWIN%\lib\vc_dll\*.dll win\Release\
+- path: win\Release
'audacity-%APPVEYOR_BUILD_VERSION%-%APPVEYOR_REPO_COMMIT%-%APPVEYOR_BUILD_WORKER_IMAGE%'
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks
like it, but would possibly need a good web page for users to find the
build they are looking for.
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but only after effort to find and install
the Redistributable msvcp140.dll; that (and similar) should be in the
zips, I think, if the zips are to be generally useful. We put the
msvcpXXX.dll files in the installers (also msvcrXXX.dlls, I don't know
why)
If you can get the locale stuff can be put in the right place, it looks
like this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub
repro. Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
  [2]https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
  [3]https://ci.appveyor.com/project/henricj/audacity/
build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
  Hi David,
  as you may well already be aware, nightly builds are
available on this
  [1][4]http://gaclrecords.org.uk/win-nightly/
  Currently, the last build was on 26 June. When the next
build
is posted
  there it will include fixes both for the closing crash, and
opening
  stereo files crash. At the moment I haven't been able to
crash Audacity
  using the current build, but you might like to have a good
try.
  David.
  On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
  Do you have a list of the âknown issuesâ?àYou said
earlier that you
  crash when switching from stereo to mono?
  Ã
  How about nightly builds?àWhere would I find the builds
that have the
  opening/closing screen fix?
  Ã
  Best,
  David
  Ã
  Ã
  Ã
  From: David Bailes
  Sent: Tuesday, June 27, 2017 6:30 AM
  To: Audacity Development
GetLinked())
  Ã
  Hi David,
  thanks, we are already have a fix for Audacity crashing on
closing.
  Unfortunately, to help with any debugging, you'd need a
build
  environment. If you don't want to do that, then it would be
still very
  useful if you could help to make sure that we know all the
  circumstances in which Audacity crashes when Jaws is
running.
  Ã
  David.
  Ã
  On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
  1. Open Audacity.
  2. Press alt+f4 to close Audacity.
  Ã
  Result; Windows says its looking for a solution to the
problem, none is
  found so I click the close button.àRinse and repeat.
  Ã
  Are there any debug builds available that might be able to
keep track
  of breakpoints?àI donât have a build environment setup,
but would be
  happy to run a debug build and try the same thing.àAny
builds with
  error reporting built in so relevant information could be
sent to
  developers?
  Ã
  Best,
  David
  Ã
  Ã
  From: David Bailes
  Sent: Monday, June 26, 2017 7:08 AM
  To: Audacity Development
GetLinked())
  Ã
  Hi David,
  what would be very helpful would be to try and find all the
situations
  in which Audacity crashes when using Jaws and the creators
update. I'm
  aware of some, for example when opening a stereo file, but
there may be
  some which I'm not aware of, and need fixing.
  Ã
  thanks,
  David.
  Ã
  On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
  I was pushed Windows 10 CE (Wince?) and Iâm now
experiencing
the
  crashes using Audacity 2.1.3 and JAWS 18 with the latest
scriptset.
  Ã
  Is there something I can do to help narrow the ishâs down?
  Ã
  Side note; how do you blind folk follow these threads
efficiently when
  the text is interspursed?àHow do you know which are the
most recent
  comments?àItâs not obvious to me whoâs comments are
whoâs. Iâm using
  Windows Live Mail... html...
  Ã
  Best,
  David
  Ã
Â
<snip>
References
2.
https://ci.appveyor.com/project/henricj/audacity-n5suy/build/artifacts
3. https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
4. http://gaclrecords.org.uk/win-nightly/
------------------------------------------------------------------------------
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-30 18:31:32 UTC
Permalink
Post by Martyn Shaw
Hi there
Post by Henric Jungheim
There would have been 9 "nightly" builds yesterday had
AppVeyor been hooked up directly (counting the green Travis
checkmarks). AppVeyor has scheduled builds too, but I have
never played with that. Once built, one would normally push
the artifact(s) to some other place.
OK, that sounds good, maybe we can push them to FH, once they are fit for
purpose.
Why 9? I know very little about this, and Travis. Others may like to
chime in. This seems like a useful thing, automating builds.
GitHub notifies the CI server (or servers) whenever changes
are pushed. The CI server then starts a build. For the 9,
I just counted the number of green marks next to the commits
for that day here:
https://github.com/audacity/audacity/commits/master
If it's a red mark, the build failed. Yellow means it is
still building. If you click the link, you wind up at the
Travis CI build for that commit.
Post by Martyn Shaw
Post by Henric Jungheim
As for the redist situation... This is a bit more
complicated with VS2015 and later thanks to the UCRT.
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/
introducing-the-universal-crt/
TLDR, I assume that you have knowledge about these things that I don't.
Post by Henric Jungheim
Win10 comes with the UCRT stuff. Systems back to Vista
should get them through Windows Update. XP needs to have
them installed.
I'm pretty sure that we / Audacity has long since stopped support for
Vista, and I think XP as well. That may simplify things.
It saves having to test on XP, but it makes little
difference to the build since it still requires the vNNN_xp
toolsets. That causes the Win7 SDK's includes and .lib
files to be used by the compiler. The default SDK ("Windows
10 SDK") only supports targeting Win7 SP1 or later.

Unless there is some new Windows feature--API call or
whatever--Audacity needs to use that isn't in the Win7 SDK,
it shouldn't make much of a difference.
Post by Martyn Shaw
Post by Henric Jungheim
AFAIK, the safest solution is to run redist
exe from MS. One could perhaps include a web link to the
download location? ("Run this if you have problems starting
the exe.")
We would like to make it as easy as possible for a.n.interestedParty to try
a 'nightly build' or a 'current build', and if it meant them going off
looking for other stuff, that would be a pain for them. My experience of
getting a suitable dll was not great (but worked), and I have some software
knowledge. Convincing Audacity folk that using VS 2015 or 2017 may be a
motivation here for you. Hopefully that wouldn't shut out other devs.
Understood. I managed to get an all static link working
last night on my x64 fork. The result is an Audacity.exe
with no external DLL dependencies other than the system
stuff like kernel32.dll. That seems like a not-unreasonable
way to deal with xcopy-deployments (i.e., the raw .exe in a
zip file). However, that requires a bit of surgery on both
the Audacity and wxWidgets build. In the process I managed
to break what is pushed to henric/audacity/x64; I'll have a
look at sorting that out shortly.

The CI build of the official Audacity master is also broken
since I'm still trying to get the locale part of the build
working.
Post by Martyn Shaw
We have to think about 'musician x' who plays guitar and keys and wants to
try the latest Audacity thingy that she has heard about on some social
media. She knows what computer she has, clicks on an appropriate link,
unzips and is ready to go, and then gives us feedback on how great (or
otherwise) the thingy was. OK, that would be ideal, how far can we go
towards that? Otherwise it's just for us geeks, which is OK as well.
There are a few different things here: A CI build that flags
a broken Windows build ASAP is desirable (the way Travis CI
does for Linux builds). A "nightly" type Windows build for
non-technical people to test is desirable. A one-line build
for release is desirable (perhaps automated on the CI
server).

I suspect the first two goals can be met with a static
Audacity.exe (built with "/MT"). Having an installer here
is possible, but a simple .zip for seems perfectly
reasonable. The last bit should probably include both an
installer package and an xcopy deployment zip (along with
the help).

In the short term, I would think that a CI build for
flagging Windows build breakage would be useful by itself.
There is nothing wrong with the current nightlies, so let
them be until there is something better.

The UCRT headache doesn't appear until VS2013 is deep-sixed
anyway. Until then, one could just copy the two runtime
DLLs.
Post by Martyn Shaw
Our traditional Win release process is detailed at
http://wiki.audacityteam.org/wiki/Release_Process/Win
you may like to review / comment on that. We don't have 'help' in the zip,
and for 'nightlies' or 'current build's we wouldn't need them either. I'm
not sure about 'locale'.
The locale build hardly takes any time, but I still haven't
figured out what is going on with the path to msgfmt on the
appveyor master build (i.e., not my x64 fork). The
appveyor.yml installs the GetText.Tools NuGet package, but
msgfmt still isn't found for the wxWidgets part of the
locale build. (The windows locale build is done in two
phases: First Audacity.mo is built with some MSBuild magic,
then a DOS .bat runs to build the wxstd.mo.)

In the x64 fork, the NuGet package is part of the locale
project and the path to the msgfmt is fixed to the one in
the package rather than relying on the PATH environment
variable to find it. There are some other changes so that
the Audacity and wxWidgets builds are done together and
without having to move the "gl_ES", "ko_KR" and "pt" files.
The last bit hasn't been pushed yet. Once cleaned up, is
there any immediate interest in a locale pull request?
Post by Martyn Shaw
TTFN
Martyn
In addition to the C++ DLL (which does depend on
Post by Henric Jungheim
the C runtime) and--IIRC--a small vcruntime DLL), this is
what would be needed to provide the UCRT runtime for the
Directory of C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
2017-06-23 20:16 <DIR> .
2017-06-23 20:16 <DIR> ..
2017-03-30 00:42 18,752 api-ms-win-core-console-l1-1-0.dll
2017-03-30 00:42 18,240 api-ms-win-core-datetime-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-debug-l1-1-0.dll
2017-03-30 00:43 18,240 api-ms-win-core-errorhandling-
l1-1-0.dll
2017-03-30 00:43 21,824 api-ms-win-core-file-l1-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l1-2-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-file-l2-1-0.dll
2017-03-30 00:44 18,240 api-ms-win-core-handle-l1-1-0.dll
2017-03-30 00:45 18,240 api-ms-win-core-heap-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-interlocked-l1-1-0.dll
2017-03-30 00:45 18,752 api-ms-win-core-libraryloader-
l1-1-0.dll
2017-03-30 00:46 20,792 api-ms-win-core-localization-
l1-2-0.dll
2017-03-30 00:46 18,752 api-ms-win-core-memory-l1-1-0.dll
2017-03-30 00:46 18,240 api-ms-win-core-namedpipe-l1-1-0.dll
2017-03-30 00:47 19,264 api-ms-win-core-
processenvironment-l1-1-0.dll
2017-03-30 00:47 20,288 api-ms-win-core-
processthreads-l1-1-0.dll
2017-03-30 00:47 18,752 api-ms-win-core-
processthreads-l1-1-1.dll
2017-03-30 00:48 17,728 api-ms-win-core-profile-l1-1-0.dll
2017-03-30 00:48 17,728 api-ms-win-core-rtlsupport-l1-1-0.dll
2017-03-30 00:48 18,240 api-ms-win-core-string-l1-1-0.dll
2017-03-30 00:49 20,288 api-ms-win-core-synch-l1-1-0.dll
2017-03-30 00:49 18,744 api-ms-win-core-synch-l1-2-0.dll
2017-03-30 00:49 19,264 api-ms-win-core-sysinfo-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-timezone-l1-1-0.dll
2017-03-30 00:50 18,240 api-ms-win-core-util-l1-1-0.dll
2017-03-30 00:50 19,264 api-ms-win-crt-conio-l1-1-0.dll
2017-03-30 00:51 22,336 api-ms-win-crt-convert-l1-1-0.dll
2017-03-30 00:51 18,752 api-ms-win-crt-environment-l1-1-0.dll
2017-03-30 00:51 20,288 api-ms-win-crt-filesystem-l1-1-0.dll
2017-03-30 00:51 19,264 api-ms-win-crt-heap-l1-1-0.dll
2017-03-30 00:52 18,752 api-ms-win-crt-locale-l1-1-0.dll
2017-03-30 00:52 28,984 api-ms-win-crt-math-l1-1-0.dll
2017-03-30 00:52 26,432 api-ms-win-crt-multibyte-l1-1-0.dll
2017-03-30 00:53 73,024 api-ms-win-crt-private-l1-1-0.dll
2017-03-30 00:53 19,264 api-ms-win-crt-process-l1-1-0.dll
2017-03-30 00:54 22,848 api-ms-win-crt-runtime-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-stdio-l1-1-0.dll
2017-03-30 00:54 24,384 api-ms-win-crt-string-l1-1-0.dll
2017-03-30 00:55 20,800 api-ms-win-crt-time-l1-1-0.dll
2017-03-30 00:55 18,744 api-ms-win-crt-utility-l1-1-0.dll
2017-03-30 00:55 1,147,712 ucrtbase.dll
41 File(s) 1,995,552 bytes
I know MS really discourages it, but one might also consider
linking the zip-deployed Audacity with the static runtime
(building with /MT instead of /MD). Statically linking with
the wxWidgets libraries should result in a stand-alone EXE.
For an installer based deployment, there's an MSM that
should take care of the runtime (I'm not sure how the
current installer is generated, but AppVeyor does have the
WiX Toolkit installed).
Alternately: One could include the C++ runtime stuff and let
Windows Update take care of the UCRT for most people, giving
XP users the link to where they can download and and run the
vcredist exe (I think it's about 15MB).
Building the help sometimes takes forever and isn't under
source control anyway. Could one build a tarball under
Linux "every once in a while" and having the Windows build
just grab a copy of that instead? It is currently not in my
appveyor.yml.
I'd can put together a pull request for the appveyor.yml
change. I suspect that if the appveyor.yml I'm using was
checked in to the official Audacity tree and someone with
write privs logged in to AppVeyor site with their GitHub
credentials and pointed AppVeyor at Audacity's GitHub repo,
it would start doing CI builds. Both Travis and AppVeyor
https://github.com/audacity/audacity/commits/master
What would be the goals for a first go-round? If the point
is to check that Windows builds work, then what I have now
is already there. If the point is to produce binaries that
are easy for the end-user to test then it is a little more
complicated. Re-enabling the "help" build means
occasionally long build times and perhaps some spurious
build failures. The existing .yml has "locale" disabled due
to long build time. I left it that way for the master
builds (I have it enabled in my x64 builds, but it is set up
a little differently since the GetText.Tools NuGet package
is handled by the locale project itself rather than being
handled in the .yml).
If we want to do something like also having a "nightly"
style build that produces a zip deployment and an .exe/.msi
installer, I could look at that too, but that would take a
bit more time and needs a few questions answered (like how
to deal with the above UCRT issues, how Audacity should be
build--which compiler, with static or dynamic wxWidgets
libraries, etc). It seems not unreasonable to start with
something perhaps a little less ambitious.
The differences I have now look like this (IIRC, the only
critical bit is the change to the AUDACITY_ROOT environment
diff --git a/appveyor.yml b/appveyor.yml
index af2f169a3..d31d5c00e 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -5,9 +5,15 @@
#if you want to work on this, please talk with us on
# https://lists.sourceforge.net/lists/listinfo/audacity-devel
#build time is circa 50 mins.
-version: 2.1.2-{build}
+version: 2.1.3-{build}
+ - master
+image: Visual Studio 2013
shallow_clone: true # reduce traffic
+ - 'echo #define REV_LONG "%APPVEYOR_REPO_COMMIT%" >
src\RevisionIdent.h'
+ - 'echo #define REV_TIME "%APPVEYOR_REPO_COMMIT_TIMESTAMP%" >>
src\RevisionIdent.h'
# install gettext tool (only used by target "locale", which is not built at
# the moment due to long duration
- nuget install Gettext.Tools
- xcopy %AUDACITY_ROOT%\win\wxWidgets_additions\wxWidgets-3.0.2 %WXWIN% /s /y /f
- xcopy %WXWIN%\include\wx\setup_redirect.h
%WXWIN%\include\wx\setup.h* /f
# build wxWidgets
- - msbuild %WXWIN%\build\msw\wx_vc12.sln /p:Configuration="DLL
Release" /target:adv,base,core,html,net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+ - msbuild /m %WXWIN%\build\msw\wx_vc12.sln "/p:Configuration=DLL
Release;PlatformToolset=v120_xp" /target:adv,base,core,html,
net,qa,wxexpat,wxjpeg,wxpng,wxtiff,wxzlib /logger:"C:\Program
Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
- WXWIN: c:\wxWidgets-3.0.2
- AUDACITY_ROOT: c:\projects\audacity
+ WXWIN: '%APPVEYOR_BUILD_FOLDER%\..\wxWidgets'
+ AUDACITY_ROOT: '%APPVEYOR_BUILD_FOLDER%'
# replace `build_script` with `build` and `configuration` when complete build
# does not exceed a duration of 1 hour
#- Release
build_script: # build all targets except of `help` and `locale`
- msbuild win/audacity.sln /p:Configuration=Release
/target:expat,filedialog,libflac++,libflac,libid3tag,
libmad,libnyquist,libogg,libscorealign,libsndfile,
libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,
portmixer,portsmf,sbsms,soundtouch,twolame,help,Audacity
/logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"
+- cmd: >-
+ msbuild /m win/audacity.sln /p:Configuration=Release;PlatformToolset=v120_xp
/target:expat,filedialog,libflac++,libflac,libid3tag,
libmad,libnyquist,libogg,libscorealign,libsndfile,
libsoxr,libvamp,libvorbis,lv2,portaudio-v19,portmidi,
portmixer,portsmf,sbsms,soundtouch,twolame,Audacity /logger:"C:\Program
Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll" &&
+ del /S win\Release\*.ipdb &
+ del /S win\Release\*.iobj &
+ del /S win\Release\*.lib &
+ del /S win\Release\*.pdb &
+ del /S win\Release\*.exp &
+ copy %WXWIN%\lib\vc_dll\*.dll win\Release\
+- path: win\Release
+ name: 'audacity-%APPVEYOR_BUILD_VERSION%-%APPVEYOR_REPO_
COMMIT%-%APPVEYOR_BUILD_WORKER_IMAGE%'
Post by Martyn Shaw
Hi there
It looks like you have Appveyor mostly sussed.
Could it be used to replace the current 'nightly' builds? It looks
like it, but would possibly need a good web page for users to find the
build they are looking for.
I tried a couple of your builds, the VS2017 win32 one did run on my PC
but only after effort to find and install
the Redistributable msvcp140.dll; that (and similar) should be in
the
Post by Martyn Shaw
zips, I think, if the zips are to be generally useful. We put the
msvcpXXX.dll files in the installers (also msvcrXXX.dlls, I don't know
why)
If you can get the locale stuff can be put in the right place, it
looks
Post by Martyn Shaw
like this can generate the same as the 'official' release zips.
So 'yes', I do think it should be set up for the official GitHub
repro. Could you work on that?
TTFN
Martyn
The current build here is for 27f706bb (exactly; none of my
  [2]https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
I can open and Alt-F4 it while JAWS is running without it
blowing up.
Note that it doesn't include the help or locale.
Should this be set up for the official Audacity GitHub repo?
The changes to get it working are only to appveyor.yml. It
works automatically, but only after I sync my fork.
The build with my hacks is running now (so far only the
x64/none/VS2017 build is done).
  [3]https://ci.appveyor.com/project/henricj/audacity/
build/1.0.74
Click the job, then "ARTIFACTS" (at the far right) to find
the .zip. It includes the locale, but in the wrong folder
(move it, and it should work).
  Hi David,
  as you may well already be aware, nightly builds are
available on this
  [1][4]http://gaclrecords.org.uk/win-nightly/
  Currently, the last build was on 26 June. When the next build
is posted
  there it will include fixes both for the closing crash, and
opening
  stereo files crash. At the moment I haven't been able to
crash Audacity
  using the current build, but you might like to have a good
try.
  David.
  On Tue, Jun 27, 2017 at 2:44 PM, David Engebretson Jr
  Do you have a list of the âknown issuesâ?àYou said
earlier that you
  crash when switching from stereo to mono?
  Ã
  How about nightly builds?àWhere would I find the builds
that have the
  opening/closing screen fix?
  Ã
  Best,
  David
  Ã
  Ã
  Ã
  From: David Bailes
  Sent: Tuesday, June 27, 2017 6:30 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  thanks, we are already have a fix for Audacity crashing on
closing.
  Unfortunately, to help with any debugging, you'd need a build
  environment. If you don't want to do that, then it would be
still very
  useful if you could help to make sure that we know all the
  circumstances in which Audacity crashes when Jaws is running.
  Ã
  David.
  Ã
  On Mon, Jun 26, 2017 at 10:29 PM, David Engebretson Jr
  1. Open Audacity.
  2. Press alt+f4 to close Audacity.
  Ã
  Result; Windows says its looking for a solution to the
problem, none is
  found so I click the close button.àRinse and repeat.
  Ã
  Are there any debug builds available that might be able to
keep track
  of breakpoints?àI donât have a build environment setup,
but would be
  happy to run a debug build and try the same thing.àAny
builds with
  error reporting built in so relevant information could be
sent to
  developers?
  Ã
  Best,
  David
  Ã
  Ã
  From: David Bailes
  Sent: Monday, June 26, 2017 7:08 AM
  To: Audacity Development
  Subject: Re: [Audacity-devel] Jaws Crashes (was: GetLinked())
  Ã
  Hi David,
  what would be very helpful would be to try and find all the
situations
  in which Audacity crashes when using Jaws and the creators
update. I'm
  aware of some, for example when opening a stereo file, but
there may be
  some which I'm not aware of, and need fixing.
  Ã
  thanks,
  David.
  Ã
  On Sat, Jun 24, 2017 at 10:38 PM, David Engebretson Jr
  I was pushed Windows 10 CE (Wince?) and Iâm now experiencing
the
  crashes using Audacity 2.1.3 and JAWS 18 with the latest
scriptset.
  Ã
  Is there something I can do to help narrow the ishâs down?
  Ã
  Side note; how do you blind folk follow these threads
efficiently when
  the text is interspursed?àHow do you know which are the
most recent
  comments?àItâs not obvious to me whoâs comments are
whoâs. Iâm using
  Windows Live Mail... html...
  Ã
  Best,
  David
  Ã
Â
<snip>
References
2. https://ci.appveyor.com/project/henricj/audacity-
n5suy/build/artifacts
Post by Martyn Shaw
3. https://ci.appveyor.com/project/henricj/audacity/build/1.0.74
4. http://gaclrecords.org.uk/win-nightly/
------------------------------------------------------------
------------------
Post by Martyn Shaw
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-07-01 20:04:35 UTC
Permalink
The current builds here are statically linked with both
wxWidgets and the C and C++ runtimes. This one is still
building, but the exe from the first job runs and has the
Language folder in the right place:
https://ci.appveyor.com/project/henricj/audacity/build/1.0.83
AFAIK, the Win32 builds should "just work" without any DLL
mucking on Windows XP to Windows 10. (The x64 builds target
the Win10 SDK since there were never all that many x64
Windows installs before Win7, and if some diehard is still
out there, they can use the Win32 builds.)

For an MSI based install, I would still suggest dynamic
linking.

I spent way too much time yesterday trying to fight the PATH
issue for building locale w/o changing the locale.vcxproj
itself. Finally, I spent far less time than that
backporting my x64 locale.vcxproj changes. The result is a
pull request rather than "audacity master" builds with a
Language folder:
https://github.com/audacity/audacity/pull/200
Post by Henric Jungheim
Post by Martyn Shaw
Our traditional Win release process is detailed at
http://wiki.audacityteam.org/wiki/Release_Process/Win
you may like to review / comment on that. We don't have 'help' in the zip,
and for 'nightlies' or 'current build's we wouldn't need them either. I'm
not sure about 'locale'.
The locale build hardly takes any time, but I still haven't
figured out what is going on with the path to msgfmt on the
appveyor master build (i.e., not my x64 fork). The
appveyor.yml installs the GetText.Tools NuGet package, but
msgfmt still isn't found for the wxWidgets part of the
locale build. (The windows locale build is done in two
phases: First Audacity.mo is built with some MSBuild magic,
then a DOS .bat runs to build the wxstd.mo.)
In the x64 fork, the NuGet package is part of the locale
project and the path to the msgfmt is fixed to the one in
the package rather than relying on the PATH environment
variable to find it. There are some other changes so that
the Audacity and wxWidgets builds are done together and
without having to move the "gl_ES", "ko_KR" and "pt" files.
The last bit hasn't been pushed yet. Once cleaned up, is
there any immediate interest in a locale pull request?
Loading...