Appveyor (was Re: Jaws Crashes (was: GetLinked()))

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Appveyor (was Re: Jaws Crashes (was: GetLinked()))

MartynShaw
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

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

The current build here is for 27f706bb (exactly; none of my
hacks are included):
   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).


On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>    Hi David,
>    as you may well already be aware, nightly builds are available on this
>    page:
>    [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
>    <[2][hidden email]> wrote:
>
>    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
>    <[hidden email]> wrote:
>
>    The simplest way for me to make Audacity crash is:
>    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
>    <[hidden email]> wrote:
>
>    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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Gale
Administrator
On 29 June 2017 at 02:09, Martyn Shaw <[hidden email]> wrote:
> 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

> 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
>
> On 28 June 2017 at 15:50, Henric Jungheim <[hidden email]> wrote:
>>
>>
>> The current build here is for 27f706bb (exactly; none of my
>> hacks are included):
>>    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).
>>
>>
>> On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>> >    Hi David,
>> >    as you may well already be aware, nightly builds are available on
>> > this
>> >    page:
>> >    [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
>> >    <[2][hidden email]> wrote:
>> >
>> >    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
>> >    <[hidden email]> wrote:
>> >
>> >    The simplest way for me to make Audacity crash is:
>> >    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
>> >    <[hidden email]> wrote:
>> >
>> >    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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Henric Jungheim
In reply to this post by MartynShaw

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%'



On Thu, Jun 29, 2017 at 02:09:14AM +0100, Martyn Shaw wrote:

>    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
>    On 28 June 2017 at 15:50, Henric Jungheim <[1][hidden email]>
>    wrote:
>
>      The current build here is for 27f706bb (exactly; none of my
>      hacks are included):
>      Â  Â [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).
>      On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>      >Â  Â  Hi David,
>      >Â  Â  as you may well already be aware, nightly builds are
>      available on this
>      >Â  Â  page:
>      >Â  Â  [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
>      >Â  Â  <[2][5][hidden email]> wrote:
>      >
>      >  Â  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
>      >Â  Â  <[6][hidden email]> wrote:
>      >
>      >Â  Â  The simplest way for me to make Audacity crash is:
>      >Â  Â  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
>      >Â  Â  <[7][hidden email]> wrote:
>      >
>      >  Â  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
>
>    1. mailto:[hidden email]
>    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/
>    5. mailto:[hidden email]
>    6. mailto:[hidden email]
>    7. mailto:[hidden email]

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

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


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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

MartynShaw
In reply to this post by Gale


On 29 June 2017 at 02:21, Gale Andrews <[hidden email]> wrote:
On 29 June 2017 at 02:09, Martyn Shaw <[hidden email]> wrote:
> 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.

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
 
Gale

> 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
>
> On 28 June 2017 at 15:50, Henric Jungheim <[hidden email]> wrote:
>>
>>
>> The current build here is for 27f706bb (exactly; none of my
>> hacks are included):
>>    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).
>>
>>
>> On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>> >    Hi David,
>> >    as you may well already be aware, nightly builds are available on
>> > this
>> >    page:
>> >    [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
>> >    <[2][hidden email]> wrote:
>> >
>> >    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
>> >    <[hidden email]> wrote:
>> >
>> >    The simplest way for me to make Audacity crash is:
>> >    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
>> >    <[hidden email]> wrote:
>> >
>> >    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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Gale
Administrator
In reply to this post by Henric Jungheim
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


On 29 June 2017 at 19:42, Henric Jungheim <[hidden email]> wrote:

>
> 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%'
>
>
>
> On Thu, Jun 29, 2017 at 02:09:14AM +0100, Martyn Shaw wrote:
>>    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
>>    On 28 June 2017 at 15:50, Henric Jungheim <[1][hidden email]>
>>    wrote:
>>
>>      The current build here is for 27f706bb (exactly; none of my
>>      hacks are included):
>>      Â  Â [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).
>>      On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>>      >Â  Â  Hi David,
>>      >Â  Â  as you may well already be aware, nightly builds are
>>      available on this
>>      >Â  Â  page:
>>      >Â  Â  [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
>>      >Â  Â  <[2][5][hidden email]> wrote:
>>      >
>>      >  Â  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
>>      >Â  Â  <[6][hidden email]> wrote:
>>      >
>>      >Â  Â  The simplest way for me to make Audacity crash is:
>>      >Â  Â  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
>>      >Â  Â  <[7][hidden email]> wrote:
>>      >
>>      >  Â  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
>>
>>    1. mailto:[hidden email]
>>    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/
>>    5. mailto:[hidden email]
>>    6. mailto:[hidden email]
>>    7. mailto:[hidden email]
>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

MartynShaw
In reply to this post by Henric Jungheim
Hi there

On 29 June 2017 at 19:42, Henric Jungheim <[hidden email]> wrote:

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.
 

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.
 


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


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
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%'



On Thu, Jun 29, 2017 at 02:09:14AM +0100, Martyn Shaw wrote:
>    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
>    On 28 June 2017 at 15:50, Henric Jungheim <[1][hidden email]>
>    wrote:
>
>      The current build here is for 27f706bb (exactly; none of my
>      hacks are included):
>         [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).
>      On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>      >    Hi David,
>      >    as you may well already be aware, nightly builds are
>      available on this
>      >    page:
>      >    [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
>      >    <[2][5][hidden email]> wrote:
>      >
>      >    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
>      >    <[6][hidden email]> wrote:
>      >
>      >    The simplest way for me to make Audacity crash is:
>      >    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
>      >    <[7][hidden email]> wrote:
>      >
>      >    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
>
>    1. mailto:[hidden email]
>    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/
>    5. mailto:[hidden email]
>    6. mailto:[hidden email]
>    7. mailto:[hidden email]

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

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


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


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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Gale
Administrator
On 30 June 2017 at 01:49, Martyn Shaw <[hidden email]> wrote:

> Hi there
>
> On 29 June 2017 at 19:42, Henric Jungheim <[hidden email]> wrote:
>>
>>
>> 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.
>
>>
>>
>> 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.
>
>>
>>
>>
>> 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



>> 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
>> 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%'
>>
>>
>>
>> On Thu, Jun 29, 2017 at 02:09:14AM +0100, Martyn Shaw wrote:
>> >    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
>> >    On 28 June 2017 at 15:50, Henric Jungheim <[1][hidden email]>
>> >    wrote:
>> >
>> >      The current build here is for 27f706bb (exactly; none of my
>> >      hacks are included):
>> >      Â  Â [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).
>> >      On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
>> >      >Â  Â  Hi David,
>> >      >Â  Â  as you may well already be aware, nightly builds are
>> >      available on this
>> >      >Â  Â  page:
>> >      >Â  Â  [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
>> >      >Â  Â  <[2][5][hidden email]> wrote:
>> >      >
>> >      >  Â  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
>> >      >Â  Â  <[6][hidden email]> wrote:
>> >      >
>> >      >Â  Â  The simplest way for me to make Audacity crash is:
>> >      >Â  Â  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
>> >      >Â  Â  <[7][hidden email]> wrote:
>> >      >
>> >      >  Â  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
>> >
>> >    1. mailto:[hidden email]
>> >    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/
>> >    5. mailto:[hidden email]
>> >    6. mailto:[hidden email]
>> >    7. mailto:[hidden email]
>>
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Henric Jungheim
In reply to this post by MartynShaw
On Fri, Jun 29, 2017 at 01:49:28AM +0100, Martyn Shaw wrote:

> Hi there
>
> On 29 June 2017 at 19:42, Henric Jungheim <[hidden email]> wrote:
>
> >
> > 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.

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

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

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

>
> 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?


>
> TTFN
> Martyn
>
>
> 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%'
> >
> >
> >
> > On Thu, Jun 29, 2017 at 02:09:14AM +0100, Martyn Shaw wrote:
> > >    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
> > >    On 28 June 2017 at 15:50, Henric Jungheim <[1][hidden email]>
> > >    wrote:
> > >
> > >      The current build here is for 27f706bb (exactly; none of my
> > >      hacks are included):
> > >      Â  Â [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).
> > >      On Wed, Jun 28, 2017 at 12:04:43PM +0100, David Bailes wrote:
> > >      >Â  Â  Hi David,
> > >      >Â  Â  as you may well already be aware, nightly builds are
> > >      available on this
> > >      >Â  Â  page:
> > >      >Â  Â  [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
> > >      >Â  Â  <[2][5][hidden email]> wrote:
> > >      >
> > >      >  Â  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
> > >      >Â  Â  <[6][hidden email]> wrote:
> > >      >
> > >      >Â  Â  The simplest way for me to make Audacity crash is:
> > >      >Â  Â  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
> > >      >Â  Â  <[7][hidden email]> wrote:
> > >      >
> > >      >  Â  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
> > >
> > >    1. mailto:[hidden email]
> > >    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/
> > >    5. mailto:[hidden email]
> > >    6. mailto:[hidden email]
> > >    7. mailto:[hidden email]
> >
> > > ------------------------------------------------------------
> > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> > > _______________________________________________
> > > audacity-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >

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

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


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

Re: Appveyor (was Re: Jaws Crashes (was: GetLinked()))

Henric Jungheim

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

On Fri, Jun 30, 2017 at 11:31:32AM -0700, Henric Jungheim wrote:

> On Fri, Jun 29, 2017 at 01:49:28AM +0100, Martyn Shaw wrote:
> > On 29 June 2017 at 19:42, Henric Jungheim <[hidden email]> wrote:
> >
> > 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?

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