We want to use the fix ups that use NuGet. However, they break the windows build-bot. At the moment the windows build-bot is more important than the better locale code - hence reverting.
Ensures that all files that Git considers to be text will have
normalized (LF) line endings in the repository. When core.eol is set to
native (which is the default), Git will convert the line endings of
normalized files in your working directory back to your platform's
native line ending.
See also https://git-scm.com/docs/gitattributes
This gets FileDialog updated and working on Windows. It also
removes removes the "wx3" build configurations and makes the default
Debug and Release builds wx3-only.
Still need to get VSTs updated.
This changes the way "unofficial" Inno Setup translations
are handled.
The first time a user compiles the .iss, the "unofficial" translations
will be downloaded to:
C:\Program Files (x86)\Inno Setup 5/Languages/unofficial
Any translations supported by Audacity that do not have an Inno
translation will be automatically created from the Default.isl in:
C:\Program Files (x86)\Inno Setup 5/Languages/dummy
This is all handled by the Inno Preprocessor. Powershell is used
to do the actual download.
Once downloaded, they will not be downloaded again, so if updates
are made, they will need to be deleted from the above directories
and allowed to download again.
In addition, I extracted the "Reset Preferences" translations from
the Audacity .po files and added them to the .iss file.
Audacity private Inno translation files are still supported in
win/InnoSetupLanguages, but I've removed the samples I'd previously
committed.
While not exactly related to this change, there were 2 languages
that weren't being set properly after being selected during
installation:
ca@valencia (Valencian)
bs (Bosnian)
The reason Valencian wasn't be displayed in preferences was twofold.
It was incorrectly named and the search loop in Languages:GetLanguages()
didn't include a range sufficient enough to pull the Valencian info.
The Bosnian language is supported by wxWidgets 2.8.12 (it is in wx3)
so, even though we have a translation, it was unavailable for
selection.
The changes required to fix those issues were:
1) Renamed ca@valencia to ca_ES@valencia
2) Instead of iterating over all wxWidgets languages and trying to
match them with our translations, I reversed it. It now iterates
over our translations and asks wxWidgets for the associated
language info. This provides support for both of the above
languages.
3) By doing #2, we are now able to add additional user languages that
may not yet be supported by wxWidgets. So, I added the Bosnian
language info.
These are mostly for getting it to build on Linux, but I've
also created new configs in Visual Studio to make it easier
to switch between wx2 and wx3.
For Linux, you have to tell configure where to find the wx3
version of the wx-config script and, since some distros build
wxWidgets v3 against GTK+ v3, you may also need to enable
gtk3 with something like:
./configure --enable-gtk3 WX_CONFIG=/usr/bin/wx-config-3.0
On Windows, I've added "wx3-Debug" and "wx3-Release" to the
existing "Debug" and "Release" configurations.
They depend on you having your WXWIN environment variable
pointing to your wx2 directory and a new WXWIN3 environment
variable pointing to your wx3 directory. For instance, I
have:
WXWIN=C:\Users\yam\Documents\wxWidgets-2.8.13
WXWIN3=C:\Users\yam\Documents\wxWidgets-3.0.2
Doing this allows you to switch freely among the 4 configurations
without having to get out of Visual Studio and monkey around with
the environment.
The project files will also add the location of the wxWidgets DLLs
to the PATH when running Audacity from within Visual Studio. They
add %WXWIN%\lib\vc_dll or %WXWIN3%\lib\vc_dll at the beginning
of the PATH variable as appropriate.
I expect that once we convert to wx3 we'll just drop back down to
the normal Debug and Release configurations, but this should make
switching between wx2 and wx3 much easier during the transition.
From what I can tell, the only thing that is "lost" because of
this is the possibility of using C++AMP. Not really an issue.
And we don't have to provide different runtimes for XP and
win7+. They all use the same redistributable package.
Renamed the VS2008 solution instead of removing it
to give people time to get VS2013 installed.
Will remove the VS2008 solution and project files
after a while.
This was NOT just a straightforward conversion. It took days to
figure out why projects kept building over and over again, so
committing is the best way for people to kick the tires.
These are completely separate from the VS2008 project files, so
they do not affect current build process.
