Keep support for the ENABLE64BIT flag (as a flag for choosing between
32 and 64 bit, if the current arch happens to be x86) but avoid using
it in code that wants to know the exact architecture used.
This makes the platform build files more straightforward and
consistent.
This is the same dirs as used as output dir by the msvc project files.
This makes sure that the project files can pick up the output files
directly instead of having to manually copy them around.
This makes sure the code is at least somewhat tested. Ideally those
assembly functions should be upgraded to work in 64 bit mode as well,
but until then it's better to actually use them in the configurations
where they can be built.
There is no problem in using the "insecure" CRT functions, as long as
they are used correctly - especially not within the test suite where
they are only are exposed to the test suite input data.
Within the library, these are used via the library internal wrappers
in codec/common/src/crt_util_safe_x.cpp, but we'd rather not use them
in the test suite - just use the normal standard C functions here.
This disables armasm warning A4509, "This form of conditional
instruction is deprecated".
The conditional instructions (such as movcs, addcs, subscs)
have been deprecated in ARMv8, in favor of conditional branches.
This isn't something that we need to take immediate action about,
though, therefore silence the warning.
Prior to 3f69873c99, there already was a mechanism for installing
the import library, used for the MSVC builds. Use that for mingw
as well, instead of adding more hardcoded rules.
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.
