This allows building two versions for different architectures at
the same time, without the built files clobbering each other.
This is very helpful when trying to track down differences between
two build configurations.
To build outside of the source tree, create the other directory to
use for building (either outside of the openh264 directory, or as
a subdirectory), enter that directory, and do
"make -f path/to/openh264/Makefile".
The -ZI option is only supported when building for 32 bit x86,
when building for x64 or for arm, it gives the warning "/ZI is
not supported on this platform; enabling /Zi instead".
-ZI is for "edit & continue" debugging, which one probably wouldn't
be doing with a build outside of the IDE anyway, so keep it simple
instead of trying to set -ZI specifically for x86 32 bit builds.
If the android test projects hasn't been built yet, the "make clean"
command will stop at "ant clean" (which fails since build.xml doesn't
exist yet). If this happens, one still would want to run the "make
clean" command to the end, cleaning up any possible intermediate object
files (e.g. from a build for a different platform).
This also avoids another manual edit in module/targets.mk. Now
the file is completely autogenerated by the build/mktargets.sh
script, just as all the other targets.mk files.
This matches the common naming scheme more closely for adding extra
flags to individual parts of the build.
Also deduplicate the static stlport lib name.
The temporary bug in gtest has now been fixed, but we still can keep
using the current way of fixing MSVC 2012 builds instead of switching
to the solution used previously.
This avoids having to disambiguate between assembler parameters,
preprocessor parameters and MSVC parameters within gas-preprocessor.
In particular, this avoids creating a stray dependency file named
'-.d' while building. Future versions of gas-preprocessor might
require this in order to build at all.
Nothing within the library actually uses these defines for anything
any more.
If necessary, the built-in defines __APPLE__ and __linux__ can be
used instead of these manually added defines. This is similar to how
we use _WIN32 instead of manually defining WIN32.
This reverts commit 09025dc8ef.
There is no need to set ASM_ARCH unless assembly sources actually
are built. ASM_ARCH is no longer used for setting unrelated CFLAGS.
All the code that relies on separating them uses the built-in defines
_WIN32 and _WIN64, or the corresponding machine defines (such as
_M_IX86, for MSVC 32 bit inline assembly).
The previous define change in 1e607d71 only made it work on MSVC
2005 and 2008, but broke things even more for 2010 and newer.
(One shouldn't override the internal details about which tuple
implementation to use, since one implementation don't work on
all versions.) Since we don't need or use the gtest tuple code,
the simplest workaround used to be just to disable it altogether,
but that was broken in r682 in gtest.
This has been tested and works on MSVC 2005, 2008, 2010, 2012 and
2013.
This reduces the build time from 69 s to 30 s, reduces the size of
the built wels.lib from 30 MB to 3.9 MB, and reduces the number of
warnings when building wels.lib.
Disambiguate between arm and arm64 sources by checking the directory
names.
The arm assembly sources can be assembled on arm64 and vice versa
without any effect since all of the implementation is hidden behind
the HAVE_NEON and HAVE_NEON_AARCH64 defines, but it still is cleaner
to not build extra empty object files than to build all *.S files
on all arm variants. (The iOS project files build all of the arm
assembly files, regardless of the target architecture, since
individual files can't easily be excluded based on the target
architecture there.)
The architecture handling is now decoupled from the main
platform file. Now you can build for Windows Phone for x86 (for
the emulator) by "make OS=msvc-wp ARCH=x86".
Windows Phone lacks the old CreateThread/beginthreadex APIs for
creating threads. (Technically, the functions still do exist,
but they aren't officially supported and aren't visible in the
headers when targeting Windows Phone.)
Building code that uses the Windows Runtime language extensions
requires building with the -ZW option.
There's no need to return to the original directory at the end of
a script - the current working directory within the subshell that
executes the script doesn't affect the working directory in the
calling shell.
When inside a git repo, attempt to change to the root dir
before running python script. Prevents a bunch of errors
when mktargets.sh is executed from the wrong dir.
This avoids having to update the makefile just to change the SDK
version whenever the iOS SDK is updated (since the previous
version is removed on updates).
Treating warnings as error is useless if no warning is activated.
Several build systems enable -Wall in the CLFAGS, which in combination
with -Werror can trigger undesired build errors.
This requires using the external gas-preprocessor tool that
converts the gnu assembler format sources to armasm format at
build time. This allows keeping the source files in one single
format but only converting while building.
The --prefix parameter differs between yasm and nasm; nasm
requires --prefix _ while yasm requires --prefix=_. Using the
define instead (as on windows) allows easier switching between
the two otherwise mostly compatible assemblers.
This fixes building with yasm on OS X in 32 bit mode. For 64 bit,
a few more tweaks are still required.
This avoids spurious changes to the targets.mk files when mktargets
is rerun on different platforms and different file systems.
In particular, OS X seems to mostly return files sorted
alphabetically, case insensitively, while they are returned in
a file system specific order on linux.
Building with "make OS=android APP_ABI=armeabi" will
produce arm binaries that will conform to the armeabi
ABI - not using any features outside of armv5te by
default (but still optionally using the NEON functions at
runtime if detected - even though such devices should rather
use the default armeabi-v7a build).
In 70360cb11, the ASM variable was moved to the x86-common file
even though the android build file didn't include neither
platform-arch.mk nor platform-x86-common.mk.
Instead of explicitly declaring ASM here, include platform-arch.mk
and remove setting of the flags that platform-arch.mk sets.
This is inspired by and based on a patch by Licai Guo.
This will make the normal C++ code not run on non-NEON devices at
all, making the runtime CPU feature detection pointless.
Adding -mfpu=neon to CFLAGS is not necessary, it's enough to
add it while building those individual .S files (via ASMFLAGS).
This doesn't build the actual demo apps that you can run on the
phone (not yet at least), but is useful for easily testing compilation
in different setups, and for building a precompiled static library for
use in external projects.
The USE_ASM variable is architecture independent now and only
controls whether assembly optimizations should be enabled in
the general sense, regardless of the target architecture.
This avoids coupling the architecture directly to the platform,
allowing building on e.g. linux on architectures other than x86,
without having to explicitly specify USE_ASM=No while building
on those.
Later this will also facilitate enabling assembly optimizations
where applicable, e.g. arm assembly on linux.
