[Audacity-devel] Cross compiling for Windows

[James Crook]

Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161

I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.


We will need to:
- Unbreak the standard Windows build
- Fix the Mac build.

Before we can pull the PR



If we want to also stage the builds for testing, we will need to:

- Support dynamic lining.
- Get our act together with regards our patched wxWidgets. (document the
patches and have them in our copy of the repo)
- Compile wxWidgets ourselves.
- Decide how/where we stage them. I don't think it's good to use GitHub
for frequent/daily builds.
- (Ideally) Package, with help and language files.

I think the packaging step can perhaps be a separate step that we do on
our own server. The work innosetup has to do to make a package is
quite light, and fetching the help files from the same server should be
fast. That would suggest we should stage them on our server too.


--James.





------------------------------------------------------------------------------

[Darrell Walisser]

Post by James Crook
Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161
I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.
- Unbreak the standard Windows build

​One breaking change I know of is:
​

Post by James Crook
- Fix the Mac build.
Before we can pull the PR
- Support dynamic lining.
- Get our act together with regards our patched wxWidgets. (document the
patches and have them in our copy of the repo)
- Compile wxWidgets ourselves.

​Yep, must be done to get our patches and also MXE doesn't have shared
library package for wxWidgets (only static)
​

Post by James Crook
- Decide how/where we stage them. I don't think it's good to use GitHub
for frequent/daily builds.
- (Ideally) Package, with help and language files.

It would be nice if "make install" copied plugins, etc as needed for
windows build. Currently it copies files for Linux (not sure how Mac is
packaged) which puts them in the wrong directories.
​

Post by James Crook
I think the packaging step can perhaps be a separate step that we do on
our own server. The work innosetup has to do to make a package is
quite light, and fetching the help files from the same server should be
fast. That would suggest we should stage them on our server too.
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Darrell Walisser]

On Wed, Sep 14, 2016 at 4:42 PM, Darrell Walisser <

Post by James Crook
- Unbreak the standard Windows build

​

​Sorry, enter key sent my mail before I was done.

OK, the breaking commit:

https://github.com/audacity/audacity/pull/161/commits/b7931feaf672acc0f1ae1dbe1c630ae7a9ed27fd

And the fix is to add nyquist/sys/win/common to header/include search path.
​

[Darrell Walisser]

Couple of new commits today, now possible to make 64-bit build for windows.
MXE packages do not support shared library version of wxWidgets so that
needs to be compiled separately.

On Wed, Sep 14, 2016 at 4:46 PM, Darrell Walisser <

Post by Darrell Walisser
On Wed, Sep 14, 2016 at 4:42 PM, Darrell Walisser <

Post by James Crook
- Unbreak the standard Windows build

​

​Sorry, enter key sent my mail before I was done.
https://github.com/audacity/audacity/pull/161/commits/
b7931feaf672acc0f1ae1dbe1c630ae7a9ed27fd
And the fix is to add nyquist/sys/win/common to header/include search path.
​

[Darrell Walisser]

Post by James Crook
Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161
I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.
- Unbreak the standard Windows build

​F​
ixed today and added to the PR. Tested on VS 2013, release build.

​

Post by James Crook
- Fix the Mac build.
​Is anyone available to help on this? I guess I could try. The mac build

directions looked a bit insane at first glance.
​


Before we can pull the PR

[Darrell Walisser]

​​

Post by James Crook
Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161
I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.
- Unbreak the standard Windows build
- Fix the Mac build.
Before we can pull the PR

​Confirmed this morning I did not break mac build. It took a while but I
was able to create VirtualBox image of 10.11 and install xcode 7.1 on it.

I have an older mac mini but it cannot take anything past 10.6 version of
OS X so it was somewhat painful to get to this point. If you want to try
the same approach I can provide an appliance file (sans disk image) that
has all the settings preloaded.

​

[Darrell Walisser]

I picked this back up about a week ago got some more issues resolved. The
VC++ build still works, I haven't been able to test Mac yet but I expect
nothing has changed.

The first major issue was dynamic linking, since MXE does not provide a
shared library of wxWidgets, I was compelled to link statically. But no
longer. wxWidgets shared lib (from git WX_3_0_BRANCH) will compile using
almost the same formula as the MXE static libs. Note that these libs are
not binary compatible with the VS libraries due to C++ ABI differences, so
nyq-bench needs to be cross-compiled as well (haven't tried this yet).

As for the build server, I have a prototype script working for Travis CI
here:
https://github.com/walisser/travis-broken-example/blob/master/.travis.yml.
To deal with the build time limitation wxWidgets is precompiled (static
lib), so it isn't a solution for release builds. But still useful to keep
things from going stale.

This can co-exist with the Linux build by using the build matrix feature of
Travis. And maybe OS X can be added too, Travis has support for it.

As far as build packaging, I haven't tried anything yet. I do not think a
separate shell script to do this is a big deal, and could be cleaner than
trying to wedge it into configure.ac and friends. It seems possible that
Travis could upload a completed build somewhere.

As a next project I might take a look at github audacity/wxWidgets and
getting it up to date with patches applied.


On Fri, Sep 23, 2016 at 12:57 PM, Darrell Walisser <

Post by Darrell Walisser
​​

Post by James Crook
Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161
I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.
- Unbreak the standard Windows build
- Fix the Mac build.
Before we can pull the PR

​Confirmed this morning I did not break mac build. It took a while but I
was able to create VirtualBox image of 10.11 and install xcode 7.1 on it.
I have an older mac mini but it cannot take anything past 10.6 version of
OS X so it was somewhat painful to get to this point. If you want to try
the same approach I can provide an appliance file (sans disk image) that
has all the settings preloaded.
​

[Darrell Walisser]

So I have been chipping away at PR 161 here and there. I hope with this
update there is now enough information to move on merging it.

To summarize the state of things:
- The patch set allows compiling Audacity for Windows, from a Unix-like
system with mxe (http://mxe.cc)
- The primary goal is to get OpenMP support on Windows.
- Compiling on Travis works, and can coexist with compiling Linux.
- Dynamic link to wxWidgets and patched wxWidgets works
- 32-bit and 64-bit binaries work
- Build steps are short and simple (see PR 161 description) note: does not
include compiling patched wxWidgets yet
- There is no change to "make install". As a result, the binaries are
packaged similarly to Linux.

Since my last message:
- Rebased to audacity/master (as of today)
- I have reviewed all commits and found a few that could be removed.
- I was able to submit a few patches to upstream libraries. One was
accepted.
- I examined the changes under lib-src and below are my notes (Hope this
helps!)

nyquist
https://sourceforge.net/p/nyquist/code/HEAD/tree/
- no changes to Nyquist upstream aside from renaming files

FileDialog
- Audacity original

lib-widget-extra
- Audacity original

libsoxr
- https://sourceforge.net/projects/soxr/
- audacity version 0.1.1, current 0.1.2
- patch is not compatible with upstream; build system was refactored

libvamp
- http://www.vamp-plugins.org/develop.html
- audacity version 2.5, current 2.7.1
- changes are compatible with upstream
- patch submitted to libvamp-devel: https://sourceforge.net/p/
vamp/mailman/message/35745614/

lv2
- http://git.drobilla.net/cgit.cgi/drobillad.git/tree/
- the changed files are part of Audacity and not upstream

mod-nyq-bench
- Audacity original

portmixer
- Audacity original

portsmf
- https://sourceforge.net/p/portmedia/code/HEAD/tree/
- audacity version SVN r227, current r230
- only code change is using intptr_t instead of long to cast pointer to int

twolame
- https://github.com/njh/twolame/
- audacity version 0.3.13 (latest stable)
- PR merged: https://github.com/njh/twolame/pull/47




On Sun, Feb 12, 2017 at 5:27 PM, Darrell Walisser <

Post by Darrell Walisser
I picked this back up about a week ago got some more issues resolved. The
VC++ build still works, I haven't been able to test Mac yet but I expect
nothing has changed.
The first major issue was dynamic linking, since MXE does not provide a
shared library of wxWidgets, I was compelled to link statically. But no
longer. wxWidgets shared lib (from git WX_3_0_BRANCH) will compile using
almost the same formula as the MXE static libs. Note that these libs are
not binary compatible with the VS libraries due to C++ ABI differences, so
nyq-bench needs to be cross-compiled as well (haven't tried this yet).
As for the build server, I have a prototype script working for Travis CI
here: https://github.com/walisser/travis-broken-
example/blob/master/.travis.yml. To deal with the build time limitation
wxWidgets is precompiled (static lib), so it isn't a solution for release
builds. But still useful to keep things from going stale.
This can co-exist with the Linux build by using the build matrix feature
of Travis. And maybe OS X can be added too, Travis has support for it.
As far as build packaging, I haven't tried anything yet. I do not think a
separate shell script to do this is a big deal, and could be cleaner than
trying to wedge it into configure.ac and friends. It seems possible that
Travis could upload a completed build somewhere.
As a next project I might take a look at github audacity/wxWidgets and
getting it up to date with patches applied.
On Fri, Sep 23, 2016 at 12:57 PM, Darrell Walisser <

Post by Darrell Walisser
​​

Post by James Crook
Darrell has put together a pull request for cross compiling for Windows.
https://github.com/audacity/audacity/pull/161
I'd like us to pull an updated version of that in at the start of 2.1.4.
For that to make sense, we will need to have a build server set up so
that this build is routinely built. Otherwise the build chain WILL GO
STALE. Travis is the obvious candidate, because it has good integration
with GitHub.
- Unbreak the standard Windows build
- Fix the Mac build.
Before we can pull the PR

​Confirmed this morning I did not break mac build. It took a while but I
was able to create VirtualBox image of 10.11 and install xcode 7.1 on it.
I have an older mac mini but it cannot take anything past 10.6 version of
OS X so it was somewhat painful to get to this point. If you want to try
the same approach I can provide an appliance file (sans disk image) that
has all the settings preloaded.
​