This isn't used anywhere in the code, floating point is just the
default unless FIXED_POINT is defined.

In the speex codebase, arch.h has a check that both FIXED_POINT
and FLOATING_POINT aren't defined simultaneously, in part as a
check that the build system was constructed with thought about
these and other defines. However, we don't have such a check
and to me it seems unnecessary code.

 On some systems (HPPA+HPUX+GCC) -fstatck-protector was causing failures not
at build or link time but at actual runtime. This is much less reasonable to
detect from autotools. It looks this this really can only safely be a white-
list, and the systems which would be whitelisted often already pick up the
setting from the OS build environment in any case.  It isn't important for
OPUS, we were just using it as belt-and-suspenders security and because it
makes some failure types easier to troubleshoot.

Further cleanup of the confusion with the version string settings.

I'm not sure how this worked before, the the previous version
string fiddling commit ended up not defining OPUS_VERSION in
the autoconf build, so opus_get_version_string() returned
'unknown'.

Previously we defined the release version string in configure.ac,
and overrode that with 'git describe --tags' if possible. This
made it difficult for non-autoconf builds to set their version
string correctly.

Instead we create, and check into version control, a file called
version.mk which defines OPUS_VERSION. The configure script reads
that file and uses it as a fallback if the git revision isn't available.

The expectation is that version.mk will be manually updated for
releases, just as the previous configure.ac version was. However,
since this is a simpler format, it is easier for alternate build
systems to use, reducing the number of places which must be updated.

Also removes the OPUS_MINOR_VERSION, etc. defines from config.h.

As best we recall, this was used to version the
library filename during rapid development. It's
no longer needed now that the bitstream is frozen
and isn't hooked up to anything in the build system.

The config.h version defines were declared in the
middle of the math feature testing. This commit moves
it to the top of configure.ac where the other version
number code resides.

- Draft updates
- Updated code to produce and check test vectors
- Making sure that the test vectors pass at all rates as well as for mono and stereo

The glibc 2.14 NEWS file says __malloc_hook will be removed
in the next release, so future-proof our use by checking
for this symbol at configure time and only compiling the
malloc failure tests if it is present.

Build tests in the tests/ directory instead of top, cleanup, rename,
and eliminate recursive make for the celt/ unit tests.

Fix stack corruption with high rate SILK encoding added by the recent CBR changes and enable -fstack-protector-all on gcc autotools builds.

Doxygen is a tool for generating programming documentation
based on comments in header and source files. This commit
adds the necessary configuration file and associated support
in the autotools build.

Right now it doesn't generate much documentation because our
public header files aren't marked up. Warnings are printed
for undocumented members and arguments.

With subdir-objects, both the top-level makefile, and
libcelt/Makefile, which runs celt-specific unit tests,
were sharing libcelt/.deps for generated dependencies.

Each thought it owned the directory, and so would remove
the files it created in that directory, followed by the
directory itself. The second makefile would then fail to
because the files it created weren't there to remove,
blocking a successful 'make distcheck' with in runs
'make distclean' as part of its verification tests.

We can work around the problem by generating the makefile
for the tests in the actual test directory, so it doesn't
share autotools scratch space with the top level makefile.

Gregory Maxwell authored 13 years ago and Jean-Marc Valin committed 13 years ago

The object code is unchanged (except ectest). Also reenables -Wparentheses, -Wsign-compare,
and the MSVC warnings.

Ralph Giles authored 13 years ago and Jean-Marc Valin committed 13 years ago

These files allow compiling and linking against the reference
implementation with an invocation like `pkg-config --cflags
--libs opus`. They're optional within the opus build system,
but can simplify compilation for clients and are generally
considered part of a normal autotools build these days.

The -uninstalled version refers to local build products
within the tree, which is helpful for testing and unprivileged
builds. opus.pc is used once 'make install' has put the
libraries and headers somewhere more permanent.