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.
This allows building (and running) codec_unittest for android.
This explicitly needs to go at the end of the LDFLAGS, since both
this and -lgtest etc. are static libraries, and code in gtest
relies on the STL. Since this explicitly needs to be at the end,
a separate makefile variable is added for it.
This fixes building of gtest on msvc.
See e.g. http://stackoverflow.com/questions/8274588 for
more discussion on the matter.
This is only required on MSVC 2012 - gtest itself (in the cmake
files) adds -D_VARIADIC_MAX=10 to the build when building using
MSVC 2012, but we don't know the MSVC version at the make stage
here. Since the gtest tuple support isn't used at all, it's
simpler to just disable it altogether than to try to add
-D_VARIADIC_MAX=10.
The main purpose is to make sure that the build doesn't fail
if the build directory contains the gtest subdirectory, although
the unittests also could be run on a device.
One doesn't need to run the ndk-build command from within the
jni subdirectory, calling it from the project top level directory
works just as well.
Also remove an unnecessary step of cd ../../../.. at the end -
since all make commands are run in a subshell, we don't need to
restore the current working directory afterwards.
MSVC doesn't export any functions at all by default, contrary to
gcc which exports all global functions by default.
Doing the same for linux/OS X isn't too hard, but they use yet
two other, different syntaxes for the corresponding symbol file.
This is enabled for platforms/compilers that support the -MMD
option, which creates a dependency file named out.d when compiling
to a file named out.o, only including local, not system headers.
The additional -MP option adds phony targets for all included
headers, to avoid having make error out due to "no rule to make
target foo.h" if a header is renamed/removed.
This makes sure that all the right files are rebuilt if a header
is changed, avoiding the need for a full rebuild if only a few
files are affected.
Don't enable threading globally since the MSVC/ARM build target
(neither windows phone nor windows rt) doesn't support the normal
windows threading functions.
This makes sure that e.g. "make clean" actually removes
the built exe files, and avoids relinking the exe files each
time make is run when cross compiling from linux to windows.
(Make on windows seems to have an exception that knows to skip
rebuilding the 'h264enc' target if 'h264enc' doesn't exist but
'h264enc.exe' does, but this exception doesn't work on normal
unix make.)
The library uses this define to enable OS X specific functionality
in general, even if none of those snippets actually have been
strictly required so far.
By setting an overridable variable in the main makefile, we avoid
having to move the default -DUNIX64 into each of the other unix
platform makefiles, but still allowing the mingw platform to
override it.
This makes sure that all the dependency libs are built before trying
to link them together, fixing parallel make (which occasionally
failed due to trying to link the encoder or decoder command line
binaries before the libs had been built) and also fixes building an
individual component by e.g. "make h264enc".
Add platform-freebsd.mk makefile to allow building on FreeBSD.
OpenH264 builds and runs successfully on FreeBSD 9.2-RELEASE amd64, with both
the gcc and clang compilers.
Note that building i386 binaries with the native toolchain using the -m32 flag
on amd64 FreeBSD is unsupported and will not work, so ENABLE64BIT should always
be set to Yes when compiling on a FreeBSD amd64 system.
