...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
This does not do the full toolchain setup like the arm builds. It only
allows for ndk-builds. See the instructions in tests/android/README or
the webm jnin bindings project:
https://chromium.googlesource.com/webm/bindings/+/master/JNI/README.Android
Because this support is not quite polished, the build targets must be
forced. Please use
--force-target=x86-android-gcc --disable-ssse3 --disable-sse4_1 --disable-avx2
--force-target-mips-android-gcc
Change-Id: Ie2b6623f71ac816e3965c39bf97097e9d30b6e94
dist is broken in msvs currently due to a dependency on libs.mk which in
turn depends on the rest of the source tree, not just the examples
Change-Id: I3e313ceeae81eb29ef4bfb099d89756b43583eaa
Temporary revert.
Problems with conflicting definitions of type off_t
in MSVC builds that need resolving.
c:\Program Files (x86)\
Microsoft Visual Studio 9.0\VC\include\wchar.h(479) :
"error C2371: 'off_t' : redefinition; different basic types
c:\on2experimental\libvpx\tools_common.h(26) :
see declaration of 'off_t'"
This reverts commit 92a4c59112.
Change-Id: I535e40a18842a92e3e6e0b29e5fba66313010803
Instead of hardcoding a certain indentation, use the regexp to
provide similar indentation for the new line as well.
Change-Id: Iacb2621b35ce7e1aa3980c1603b8e3ab02d98a35
This makes sure that labels for data symbols directly after
functions get properly 4-byte-aligned (when the source is assembled
in thumb mode).
Previously, if declaring a data symbol directly after a function, the
symbol could end up pointing to the unaligned address (if the total
size of the thumb function didn't end up being a multiple of 4). The
data in the symbol itself ended up aligned, but the symbol pointed to
the preceding unaligned position.
That is, a source file looking like this:
---
...
ENDP
symbol
DCD 0x12345678
---
could end up being assembled into
symbol:
xxxxx2: 0000
xxxxx4: 5678
xxxxx6: 1234
(This doesn't happen if the symbol label is on the same line as the
DCD directive.)
By adding an ALIGN 4 directly after the ENDP we make sure the symbol
itself gets aligned properly.
This isn't an issue with the original, untranslated arm source,
since it only is built in arm mode where all instructions are 4 byte,
and since the gnu assembler automatically adds the padding before the
symbol even in thumb mode.
Change-Id: Iadbeebd656b0197e423e79a12a7d3ef8859cf445
<=sse2 isn't strictly necessary on x86_64, but this is more consistent
with the rest of the flags and should be harmless
Change-Id: Ice0f1d1c4c7510ee90af2a62dbd3d6508db63487
The comment made it look like the condition code was dropped from
the extra add instruction, while it actually was handled properly.
Thus, the comment was misleading while the code itself did the right
thing.
Also clarify the comment indicating that we use the full three-operand
form of the add instruction.
Change-Id: I2c1ac6ac4fedf262d104ea30a6c005febc74de9c
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
fixes issue #711
specifying a multiword CC, e.g., CC='gcc -m32', would cause the failure
under dash
reported in
https://bugs.gentoo.org/show_bug.cgi?id=498136
patch by floppymaster at gmail dot com
Change-Id: I2ba246f765646161538622739961ec0f6c2d8c2d
clang on macosx does not support -Wunused-but-set-variable; adding the flag
causes additional warnings about the flag. As a more generalized fix, use
-Werror when checking compiler flag support in order to avoid using
unsupported warning flags.
Change-Id: I2529862e211f880d56491eac3b9fa90fff1aa5c3
Configuration logging is passed through pr, but nothing configure
does actually requires pr. Use cat instead.
Change-Id: I451217882a329c2bfb8942ac86ac624a7feef670
significantly speeds up file generation.
the goal of this change is to convert rtcd.sh to perl as directly as
possible to allow for simple comparison. future changes can make it more
perl-like.
---
Linux
[CREATE] vpx_scale_rtcd.h
real 0m0.485s -> 0m0.022s
[CREATE] vp8_rtcd.h
real 0m4.619s -> 0m0.060s
[CREATE] vp9_rtcd.h
real 0m10.102s -> 0m0.087s
Windows
[CREATE] vpx_scale_rtcd.h
real 0m8.360s -> 0m0.080s
[CREATE] vp8_rtcd.h
real 1m8.083s -> 0m0.160s
[CREATE] vp9_rtcd.h
real 2m6.489s -> 0m0.233s
Change-Id: Idfb71188206c91237d6a3c3a81dfe00d103f11ee
- 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
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
Avoid substitution of substrings by using \b to make sure the
substituted strings are at word boundaries.
This is an adaption of the corresponding changes to ads2gas.pl
from 7ebcaeb0fa.
Change-Id: I52160e8ba0373d4779d5fc3b0c384ca5c51c7b13
older versions of visual studio did not include the trailing \. this
moves the objects to their intended location: the project subdirectory
Change-Id: I244479cdebf6b3f03bed6dbfca82e7fb4542f0de
Filter out files ending in _neon.c and append .neon so the Android build
system knows to apply -mfpu=neon
Change-Id: Ib67277e5920bfcaeda7c4aa16cd1001b11d59305
VS2010 only supports avx. There is currently no avx code
in libvpx so don't create a special case for it.
Change-Id: Iacb10ea4762155412e04f23904b4324d01451fbd
Upstream changes to account for differences in clang
syntax for Chromium iOS builds.
Since most of these are incompatible with XCode clang,
hide them behind a flag.
Change-Id: Idafcbcd4eb01b1ada6277da2d2edfd6c04b579fd
Match any whitespace instead of individual spaces. The macro
definitions in vp9/common/arm/neon/vp9_short_idct32x32_1_add_neon.asm
triggered this and treated spaces as arguments leading to lines like:
$8vld1$8.$88$8 {$8q8$8}, [$$89$8], $$8stride$8
Change-Id: I2d5718aba4614e4fd7b702e15c2a1bd80e656bd2
"-no-prec-div" option helps codec performance, so it was added back.
"-no-intel-extensions" was added to suppress link warning #10237.
option '-use-asm' is deprecated and removed.
Tested icc 32bit build and 64bit build.
Change-Id: I736ec2619857efd425ef76338dc52f8fbc0bcc7e
Include the whitespace after the first argument's comma in the
optional first argument group.
This fixes a minor style regression in the converted output
since 2a233dd31.
Change-Id: I254f4aaff175e2d728d9b6f3c12ede03846adcf1
Now the same regexp that previously handled cases such as
"ldr r1, [r2, -r3]" also can handle the first operand being omitted
as in "pld [r2, -r3]".
This fixes building vp9_convolve8*neon.asm in thumb mode (and thus,
for Windows Phone as well).
Change-Id: I20c1c3f2bfb2587fb5fa523b863972a7fe30d8ff
+ disable() -> disable_feature() for balance
this avoids shadowing the bash builtin 'enable' allowing the scripts to
be linted with checkbashisms
Change-Id: Ia11cf86c92ec25bd14e69427b0ac0a9a61a5f7a5
The conversion was done with the help of the checkbashisms script
and https://wiki.ubuntu.com/DashAsBinSh .
Change-Id: Id64ecefb35c8d72302f343cd2ec442e7ef989d47
Support enabling it or disabling it. Moved read out to configure.sh
so that its done once instead of in make and in config.
Change-Id: I73a9190cf31de9f03e8a577f478fa522f8c01c8b
Prior to 73c4e284, the generated .sln files didn't contain any
information about the different configurations when using .vcxproj
project files. The MSVS IDE was able to fill this in just fine when
loaded though.
When building for ARM, the obj_int_extract project still is built
for x86, in order for the build process to be able to use
obj_int_extract.exe.
Now that configuration info is generated, it breaks current ARM
setups, since the configurations generated by gen_msvs_sln.sh only
included configurations from the last parsed project file (as
mentioned in the comment).
In these setups, the MSVS IDE generated a third meta-platform, called
"Mixed Platforms". This meta-platform points to either ARM or
Win32 as platform in each of the individual projects.
When the MSVS IDE generated this automatically, it also included
the original ARM and Win32 platforms as separate choices, but these
can be omitted since they don't make sense.
Change-Id: Ie25226496f91af4bb1ad8eb9ae9ca5bfed0433d7
quiets a warning on every file; the preference is to use a 64-bit
compiler, which is readily available at and above this version.
Change-Id: I56e7eb569022e7148249d93fe386ad5ea0eee3fc
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
The branch instructions are encoded as 16 bit instructions
by the microsoft assembler, while they are encoded as 32 bit
instructions by gnu binutils.
Change-Id: I622b9025df3520c08eef8447df078f5517fb4b67
This is required since the microsoft assembler claims that
add.w r12, pc, #10
generated unpredictable behaviour.
Change-Id: Ia8e1830def965c88ca4e2f48a24107bac6a4cb9d
The formats are basically the same, but a few minor details need
to be adjusted. Addiitonally, when building for the WinRT/Windows
Phone 8 platforms, one has to build for thumb, so convert instructions
accordingly.
Change-Id: I3c3902aa20fd3bfc29168d3a1bf17111e5481dcb
