Refocus on VS2015 .. continued FYI

Building and customizing Audacity from the source code.

If you require help using Audacity, please post on the forum board relevant to your operating system:
Windows
Mac OS X
GNU/Linux and Unix-like

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Thu Apr 21, 2016 8:19 pm

rachalmers wrote:The points you make above, 1, 2, 3 and 4 are very valid. And yes, it's a bunch of work. That's for sure.
I'm beginning to think that the "supported compilers" could well be narrowed down a bit in any case.
As for this (our) focus area, probably reducing the list to VS2013, and VS2015 builds for Windows platforms would work as I think you suggest. That's practically everything working for the VS2013 and prior people - come on guys, upgrade even... - and the newer build dragging their feet into the 21st century with VS2015. Keeping in mind that VS2015 is actually VS2014 ??? Very strange. But I guess if you are going from Windows 8 to windows 10, a Release Number jump is now the new black... Who knows.

It's simpler than that. There is a product version number that goes way, way back and then the marketing folks name the product after the year when it is released. The fact that the version numbers are nearly the same as the last two digits in the product name is an unfortunate coincidence. See here (that table claims that v15 has been released; it is only in preview). Note that they skipped version number 13.

The list of supported platforms and compilers is an Audacity project policy decision, and not for me to decide, but I agree with you that limiting things to VS2013 and VS2015 seems reasonable.
rachalmers wrote:So long as a binary can be compiled for each of the (windows) platforms, users will be happy.
Win-32: Windows 98 up to Windows 10
Win-64: Windows 8 and above
I mean there has to be a cut off point somewhere, otherwise programmers are still trying to compile versions for the 6 Windows 98 users left...

Fortunately, Windows 98 has not been supported since VS2005 (IIRC). The v140 compiler supports targeting Vista and later (also, IIRC); the v140_xp supports targeting XP and later. MS seems to have done a much better job with regard to backwards compatibility than Apple.
rachalmers wrote:and why would one stick with the old compilers when VS2015 Community is free, along with the SDK's etc. Free as. I fail to see the reasoning. Any programmer worth their salt will surely want to update to the latest gear. Maybe that's just me?

There is something to be said for not riding the bleeding edge and later versions of the tools drop support for running on older versions of Windows. I'm not sure if VS2015 and VS2013 have the same system requirements (for installing/running, I mean, not for targeting). That said, I wouldn't call VS2015 "bleeding edge" since it's a year old and already on Update 2. Furthermore, Microsoft finally made language standards compliance a priority in the last couple of years, of which much more of that has made it into VS2015 than VS2013.
rachalmers wrote:Especially considering as VS2015 builds for either 32 or 64.

64-bit support goes way back (VS2005?). I had not mentioned it for VS2013 to cut down on the number of permutations to implement/test, but with the .props file approach, it should be trivial to support targeting x64 with VS2013 as well.
rachalmers wrote:So it's down to the source code again, to put in the switches.

Now, I had a look this morning. Pulled a fresh copy from your github repo, and build the x64 Debug version. I started at the top of the list of Warnings, and went hunting.
It's painstaking, but not difficult. I started by watching for the platform and inserting _int64 where it may work better. It certainly stops the warnings in those 2 sections.

Example.
Beginning line 36 in id3tag.h, for this one. Removed the first warnings. Using a couple of handy defines in case I need them later. (code from Stackexchange)

Code: Select all
typedef unsigned char id3_byte_t;
// Check windows
#if _WIN32 || _WIN64
#if _WIN64
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

// Check GCC
#if __GNUC__
#if __x86_64__ || __ppc64__
#define ENVIRONMENT64
typedef __int64 id3_length_t;
#else
#define ENVIRONMENT32
typedef unsigned long id3_length_t;
#endif
#endif

//typedef unsigned long id3_length_t;

[/code]

So it looks like working through the .c files may be the big mission for this. I can't see any other way of getting around - globally in a .h file, the problem of declarations in the .c files. Maybe I'm wrong.
anyway, we'll see what happens. I am happy enough at the moment to just potter along here. I may put this all into my own repo, rather than get involved with commits to the master.

Robert

I'd suggest using the official names for those types (stdint.h) (if a particular platform doesn't have them, then add them with a typedef until they get their act together). Ideally, most variable definitions should be applicable to all the supported platforms (Linux, OSX, Windows), with the per-platform magic happening in typedefs and/or #defines. With a lot of gunk around the variable definition, one can wind up replicating nearly the same gunk when one needs to assign that variable or when declaring functions or methods where it needs to be passed as an argument.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Fri Apr 22, 2016 8:40 am

henric wrote:Fortunately, Windows 98 has not been supported since VS2005 (IIRC). The v140 compiler supports targeting Vista and later (also, IIRC); the v140_xp supports targeting XP and later. MS seems to have done a much better job with regard to backwards compatibility than Apple.

There is something to be said for not riding the bleeding edge and later versions of the tools drop support for running on older versions of Windows. I'm not sure if VS2015 and VS2013 have the same system requirements (for installing/running, I mean, not for targeting). That said, I wouldn't call VS2015 "bleeding edge" since it's a year old and already on Update 2. Furthermore, Microsoft finally made language standards compliance a priority in the last couple of years, of which much more of that has made it into VS2015 than VS2013.

64-bit support goes way back (VS2005?). I had not mentioned it for VS2013 to cut down on the number of permutations to implement/test, but with the .props file approach, it should be trivial to support targeting x64 with VS2013 as well.

I'd suggest using the official names for those types (stdint.h) (if a particular platform doesn't have them, then add them with a typedef until they get their act together). Ideally, most variable definitions should be applicable to all the supported platforms (Linux, OSX, Windows), with the per-platform magic happening in typedefs and/or #defines. With a lot of gunk around the variable definition, one can wind up replicating nearly the same gunk when one needs to assign that variable or when declaring functions or methods where it needs to be passed as an argument.


Thanks for the comprehensive discussion, it helps to make things lot clearer, as I'm coming to this from a long way back. Just getting my head around it has been an exercise. Fortunately VS helps. Like XCode, you can work right within the interface for 99% of requirements.

I like the idea of the .props file approach. So much neater. and much easier to understand initially.
The code examples I gave are simply to demonstrate the location, or foundation of a lot of the errors, and how relatively it is to cure a lot of them. Sometimes. The first example is in a code block in id3tag.h and I think one in a .c file - the one in the .c file was a declaration within a function - very local. I can't remember off the top of my head, but that one would be difficult to solve other than by locating it, and changing it right there, or having to re-write the whole file so such declarations weren't hidden in local functions. Found it, file.c , about L213, Commented /* check for duplication/overlap */. the code I commented out and placed into the #if block, //unsigned long begin1, begin2, end2; which is in lib-src\libid3tag\file.c
Anyway, as you say, there will be easier solutions, but it is a bit of a mission. The warnings mostly come in
libid3tag
libmad
libflac
libnyquist
libsndfile
libvorbis
twolame
libvamp
lv2
Audacity
... and a smattering of others. By far the predominant warning code seems to be C4244.
C4244 - 309 of 807
C4267 - 168 of 807
C4456 - 84 of 807

or, C42xx - 478 of 807
Anyway, a mission which ever way you look at it. and one that has implications for the OSX work as well. I'll begin exploring...

Thanks for the pointers - forgive the pun, none intended - this is really interesting, and having left C in any form alone for years, I'm enjoying the re-focus on it.
Robert
EDIT: ps. I now have the following. github.com/ShanghaiTimes/Audacity2015 Which works like this.
I do a pull from your (henric) github branch repo for vs2015, fiddle with the Warning fixes here, and Push the results to my own github ShanghaiTimes/Audacity2015 repo. Which aren't very many at the moment granted - but it's working, and it's interesting to track down those little suckers, and fix them so that I don't - hopefully - completely break the sources for others.
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Sun Apr 24, 2016 2:37 pm

The Wiki for this is here.
My grateful thanks to henricj, without who's kind assistance and hard work, I would not have got this far for a long long time.

http://wiki.audacityteam.org/wiki/Build ... tudio_2015

Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Mon Apr 25, 2016 5:07 am

rachalmers wrote:I like the idea of the .props file approach. So much neater. and much easier to understand initially.

You can take a look at my vs2013 branch, which is where I've been staging things before creating pull requests (note well: I do a rebase master after every merge to the vs2013 branch, to keep things sane for creating pull request branches). It adds an audacity.props file along the lines of what was discussed above. The way it works was changed a bit since unlike the wxWidgets variant, it creates a property one uses to set the property in the actual project file instead of setting the toolset version directly. That way, it shows up in the UI as toolset version of $(AudacityPlatformToolset), which should make it obvious that something other than the UI is setting that parameter. It uses the Visual Studio version to set the compiler toolset, lets one override WXWIN with WXWIN_VS2013 or WXWIN_VS2015, and puts all the build gunk under a "build" folder (and includes the compiler toolset in the path). The upshot of all that is that one can have the same audacity.sln file open in both VS2013 and VS2015 at the same time. One can also get rid of all the build products by deleting a single directory. There is still a link problem when building with the v140 toolset that I seem to recall from the vs2015 branch, but I haven't gotten as far as remembering or rediscovering the fix yet (the vs2015 branch still works, but only works on VS2015 since it does not have the audacity.props change). Some of the changes have already been turned into pull requests (124, 127, 128).

The .props file change touches all the vxcproj files, still has a link problem when building with VS2015, clobbers the ny.props/ny.rules/ny.targets stuff for some simpler file copying code. So it needs a bit more thought before moving towards a pull request. Note that only some of the Nyquist files used the ny.* code; some was copied directly in the Audacity.vcxproj MSBuild file. I don't think either handled the Clean or Rebuild targets properly. It is cool to have an entry in the UI, but it should be consistent for all the files and given the nature of those parameters, seemed overly complex for the purpose. At any rate, I had trouble getting it to work with my .props change, so I simplified it and made things more consistent. Even if one wants to go down that route, the *.ny, *.lsp, *.raw copying changes should be split into a separate change. The work-in-progress looks like this: Add audacity.props to support using multiple versions of Visual Studio.
rachalmers wrote:The code examples I gave are simply to demonstrate the location, or foundation of a lot of the errors, and how relatively it is to cure a lot of them. Sometimes. The first example is in a code block in id3tag.h and I think one in a .c file - the one in the .c file was a declaration within a function - very local. I can't remember off the top of my head, but that one would be difficult to solve other than by locating it, and changing it right there, or having to re-write the whole file so such declarations weren't hidden in local functions. Found it, file.c , about L213, Commented /* check for duplication/overlap */. the code I commented out and placed into the #if block, //unsigned long begin1, begin2, end2; which is in lib-src\libid3tag\file.c

I have nothing against fixing warnings, but do keep in mind that every change to something that comes from an upstream repository means more work the next time one integrates a new version of the upstream code. I'm not trying to discourage you, by any means, but keep in mind that when creating pull requests, it is generally more difficult to get things approved if they are not only massive, tree-spanning things but also mix different changes together.
rachalmers wrote:... and a smattering of others. By far the predominant warning code seems to be C4244.
C4244 - 309 of 807

This is implicit integer narrowing, IIRC. Legal code, but that is probably not one of the better aspects of C/C++ (which is why there are warnings available). I seem to recall that there are some places in the tree that suppress that error, either with #pragma directives directly in the code or by settings in the .vcxproj files.
rachalmers wrote:Anyway, a mission which ever way you look at it. and one that has implications for the OSX work as well. I'll begin exploring...

When cleaning up those sorts of things for my Nyquist fork, it got to be more that a little tedious. One needs to be on a mission for that sort of thing.

rachalmers wrote:Thanks for the pointers - forgive the pun, none intended - this is really interesting, and having left C in any form alone for years, I'm enjoying the re-focus on it.

Robert
EDIT: ps. I now have the following. github.com/ShanghaiTimes/Audacity2015 Which works like this.
I do a pull from your (henric) github branch repo for vs2015, fiddle with the Warning fixes here, and Push the results to my own github ShanghaiTimes/Audacity2015 repo. Which aren't very many at the moment granted - but it's working, and it's interesting to track down those little suckers, and fix them so that I don't - hopefully - completely break the sources for others.

I'll take a look.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Mon May 02, 2016 1:54 am

rachalmers wrote:I like the idea of the .props file approach. So much neater. and much easier to understand initially.

The audacity.props idea is now pull request 131. VS2015 builds should work given some other pull requests (127, 128, and possibly 124 as well). Of course, VS2013 still builds and runs with or without those pull requests.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by rachalmers » Mon May 02, 2016 9:34 am

henric wrote:
rachalmers wrote:I like the idea of the .props file approach. So much neater. and much easier to understand initially.

The audacity.props idea is now pull request 131. VS2015 builds should work given some other pull requests (127, 128, and possibly 124 as well). Of course, VS2013 still builds and runs with or without those pull requests.


In a pull from henrij/audacity today, I got a glitch in ThemeAsCeeCode.h ..
... to Theme.cpp and its header file. Well the header file actually... ThemeAsCeeCode.h ?.
There are some extra bits in there that don't belong . I'm just looking at the Master and commits to see if you've probably fixed that already.

Edit: The 131 Pull - and the three previous- looks good. Should make life a lot easier.
x64 Release built under VS2015 runs well. Seems very fast actually, although I haven't clocked it at all.
Audacity v2.1.3-alpha-May 2 2016


Robert
rachalmers
 
Posts: 163
Joined: Wed Jan 06, 2016 10:53 am
Operating System: OS X 10.11 El Capitan or later (macOS)

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Wed May 04, 2016 5:41 am

rachalmers wrote:
henric wrote:
rachalmers wrote:I like the idea of the .props file approach. So much neater. and much easier to understand initially.

The audacity.props idea is now pull request 131. VS2015 builds should work given some other pull requests (127, 128, and possibly 124 as well). Of course, VS2013 still builds and runs with or without those pull requests.


Edit: The 131 Pull - and the three previous- looks good. Should make life a lot easier.
x64 Release built under VS2015 runs well. Seems very fast actually, although I haven't clocked it at all.


As soon as I get a chance, I'm going to bring the audacity.props change to the vs2015 branch as well. Come to think of it, that would make it more of an "x64 branch". Hmmm. Perhaps I'll create a new x64 branch from vs2013 and then pick changes from the vs2015 branch.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Wed May 04, 2016 1:45 pm

henric wrote:As soon as I get a chance, I'm going to bring the audacity.props change to the vs2015 branch as well. Come to think of it, that would make it more of an "x64 branch". Hmmm. Perhaps I'll create a new x64 branch from vs2013 and then pick changes from the vs2015 branch.


There's now an x64 branch, based on the vs2013 branch with the x64 changes picked from the vs2015 branch. It seems to work for Win32 and x64 binaries in both VS2013 and VS2015.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Wed May 04, 2016 4:19 pm

henric wrote:There's now an x64 branch, based on the vs2013 branch with the x64 changes picked from the vs2015 branch. It seems to work for Win32 and x64 binaries in both VS2013 and VS2015.


I spoke too soon... The 131 pull request just got an update.
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

Re: Refocus on VS2015 .. continued FYI

Permanent link to this post Posted by henric » Thu May 12, 2016 7:34 pm

henric wrote:There's now an x64 branch, based on the vs2013 branch with the x64 changes picked from the vs2015 branch. It seems to work for Win32 and x64 binaries in both VS2013 and VS2015.


The x64 branch can now be built for both static and dynamic linking, on both VS2013 and VS2015, and for both Win32 and x64 binaries. There are some batch files to make doing so easier.

For a full build with both statically and dynamically linked versions of Audacity using both VS2013 and VS2015,
  • Clone my x64 branch.
  • Get two clean wxWidgets directories set up. Set the environment variable WXWIN_VS2013 to point to one and WXWIN_VS2015 to the other; they must be different directories in order to keep the VS2013 and VS2015 build artifacts from clobbering each other. (I've been testing with a copy of wxWidgets v3.0.2 for VS2013 and a copy of v3.1.0 for VS2015.)
  • Apply the wxWidgets patches from win/wxWidgets_additions. The props.diff patch will only work with v3.1.0.
  • If you need the translations, do a NuGet package restore either by doing a build of any configuration in Visual Studio or by running "nuget.exe restore audacity.sln" on the command line.
  • Run win/build_all.bat.

The build script will build all the wxWidgets configurations and then build all the Audacity configurations. It may take a while (this box takes nearly two hours). After it is done, there should be 28 MSBuild log files in win/build and 12 Audacity executables under win/build/bin (it's 12, not 16, since the batch files don't try to build the "Static Debug" variants).
henric
 
Posts: 28
Joined: Sun Jan 17, 2016 9:12 pm
Operating System: Windows 10

PreviousNext

Return to Compiling Audacity



Who is online

Users browsing this forum: No registered users and 2 guests