GitLab

use win32/win64 instead of $(PlatformName) (Win32/x64) for compatibility
with yasm 1.3.0. both format types were available since at least 0.8.0

BUG=843

Change-Id: I7917620490d0663b118ff08b96d1e5dbccba3703

strip trailing '/' from paths, this is later converted to '\' which
causes execution errors for obj_int_extract/yasm. vs10+ wasn't affected
by this issue, but make the same change for consistency.

gen_msvs_proj:
+ add missing '"' to obj_int_extract call
  unlike gen_msvs_vcproj, the block is duplicated
  missed in: 1e3d9b9e build/msvs: fix builds in source dirs with spaces

Change-Id: I76208e6cdc66dc5a0a7ffa8aa1edbefe31e4b130

execute fix_path once on the source file list rather than once per entry

Change-Id: Ibc8226e391b3028c1b0bcfeab83c790387c9fe23

reduces the risk of exceeding msbuild command line length limits

Change-Id: I0e4d807f42c090a709a3dc365a02b929a3071688

...when configured below the path containing spaces. configuring outside
the path containing spaces still won't work due to issues with the
makefiles, e.g.,
/path with spaces/git
/path with spaces/build1
/build2
configure/make in build1 will work, build2 will not

Change-Id: Ie4a1f313596d7457cadd67476ac1dbd3273ad46e

The microsoft build tools explicitly disallow building for arm in
the "desktop" target configuration; one has to target "Windows
Store" apps (aka WinRT/Metro) or Windows Phone. In Visual Studio
2012, one could just pick the v110_wp80 toolset which made the
vcxproj files buildable. In Visual Studio 2013, picking the v120_wp81
toolset isn't enough - one has to configure the vcxproj files
as an "AppContainerApplication". This has the implication that
you can't just build a plain .exe (such as the examples) - an .exe
project would need to have an AppxManifest file. Therefore we can
only build the library itself.

If loaded into Visual Studio for Windows (the Windows Store/Phone
version of Visual Studio, not the Desktop one), the obj_int_extract
project is omitted since it's treated as incompatible. Building
from the command line with msbuild works fine though.

The armv7-win32-vs12 target was added as part of a638bdf4 even
though actual use of it hadn't been tested.

Change-Id: Iee8088252cf790317aeb6b417d29058225f1f629

-> msvs_common.sh

Change-Id: Id4878805183c0ec11e5d681e4bf820b598b085f9

Change-Id: I2f05a5d90b3ad6250d31f7b422af4c22527177d1

Change-Id: I21cdaeea33a56dd4c0e38c36d01f338b1ab04c74

translates to TreatWarningAsError (/WX)
setting this via the CL environment variable is not possible due to the
/WX- default which is used on the command line

Change-Id: I0b42a9d3ca9eba6af82c25b8e434baa2fcb00156

- Update the vcxproj generator to pass the path to the batch file.
- Update the batch file the take the path to obj_int_extract.exe as arg
  2.

Fixes this warning:
warning MSB8012: TargetPath does not match Linker's OutputFile property
value.

Change-Id: I5825f1d1d79f370aeb295bbd2aeb08b22c0e73ab

Set TargetName for library builds instead of changing the value of
OutputFile.

This fixes the following warnings:
warning MSB8012: TargetPath does not match Library's OutputFile property
value.

Change-Id: I4320b6d9ea922d3a15b9823c7c6694ee33edbf45

Fixes the following warning:
warning LNK4042: object specified more than once; extras ignored

Change-Id: Icee24073be774e7f7902587449fb90a42ab16b6f

Turns on AVX when the final characters of .c and .cc file names preceding the
.c and .cc file extension contain the substrings avx or avx2. This silences
many MSVC warnings issued during compilation files that use AVX.

Change-Id: I82bda394af7a688679abab2a50dd7e10b3cb0c7a

Change-Id: I5f979135d371c3fc7b9485e29479f112baa5fa3b

Change-Id: Iccc15aacee1fee9995dfd974bc89913891ad67a9

The arm assembly files are named .s after conversion, to reuse
as much of the existing makefile infrastructure for conversion to
gas format as possible. Within the generated visual studio project,
only the converted assembly sources are available, which might not
be optimal for actually developing it, but is acceptable for
just building the library.

Multithreading is disabled since the traditional win32 threading
functions aren't available on WinRT/Windows Phone 8.

Building of vpx itself and the examples succeed, while building the
tests fail due to them using functions not available in the
windows store/windows phone API subsets - therefore the unit tests
are disabled.

This works for building in Visual Studio Express 2012 for Windows
Phone, while Visual Studio Express 2012 for Windows 8 (for
"Windows Store" apps) seems to reject the vcxproj files due to
not supporting "classic style native application or managed
projects". The built static library should be compatible with that
platform though.

Change-Id: Idcd7eca60bfaaaeb09392a9cd7a02e4a670e3b30

Change-Id: I3c23a2ce383d9291a823d2be7364608ce0e01570

Change-Id: If02a7b85f417b9693dcdab73573fc13f67e17016