Ok, great. Now - is this to become part of the main git repository? or will it stay on your branch? Could have saved me hours, days even ... if I"d known about it
At the moment, I'm pulling directly from your git repos, via the VS2015 interface. I originally did a git clone, but now can use it directly - so if you make changes, I should see them directly. nice
Thanks for the heads up. Really appreciated.
It seemed responsible to pursue upstream library changes before pushing things further in Audacity (which lead to the aforementioned wall dent). Also, since my goals at the outset were more focused on exploring VS2015's x64 than directly producing pull-request appropriate changes, there is a bit of work to disentangle required changes from unrelated or needless changes (one of the steps I took to identify x64 issues was have the compiler barf on every implicit integer conversion that involved a pointer and then fix them; some of those changes would fix trouble, but some would not). When I brought this stuff up before things got a bit sidetracked (also, Audacity 2.1.2 was pending and wxWidgets did not yet support VS2015).
The changes needed to get 32-bit VS2015 builds working should not be too hard to get into pull-request suitable form. If VS2013 provides stdint.h and inttypes.h, then deleting the local versions would be enough; if not, then moving them might be more appropriate than what the vs2015 branch does.
I've been merging/pushing Audacity master branch changes about once a week, but I'll avoid doing the "git rebase -X ignore-space-at-eol master" thing if others are tracking this. I'll hold off doing so again until travis is happy (I saw the same problem with Visual Studio).