This makes it clearer which ones actually are real platforms
(chosen automatically or explicitly via "make ARCH=foo") and which
ones just are shared helpers.
This fixes building for android on windows.
Building for android on windows still requires MSYS for running make,
but running the ndk-build of the sample projects from within MSYS
doesn't seem to work (the OS variable from the OpenH264 makefile
interferes with the host system detection in ndk-build), so one still
needs to build it in two steps, first make OS=android ... libopenh264.so,
then building the sample projects manually.
If the user selects a nonexistent ARCH, previously the call that
sets TOOLCHAINPREFIX would set it to contain a long error message,
which makes it quite hard to figure out what actually went wrong.
Instead check that CXX=$(TOLCHAINPREFIX)g++ actually points to a
working executable, and abort immediately if this isn't true.
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.
