Doing it this way means it's only the weird corner case that actually
pays for being weird, and we don't litter the build dir with an extra
link that normal builds really don't need at all.

It also avoids the problem of platforms where LN_S isn't well defined.

Mostly this is for people building other things using an uninstalled
opus tree so that the opus-uninstalled.pc will return a working -I
with --cflags when PKG_CONFIG_PATH is set to point to the build dir.

The version of AC_OUTPUT that takes parameters has long been
deprecated now, and replaced by AC_CONFIG_* macros, so pass them
with AC_CONFIG_FILES, since we're now using AC_CONFIG_COMMANDS
to do the above.

The floating-point build calls a number of math library
functions, and linking with libm is technically necessary.
It wasn't obvious because most systems support shlib
dependencies and pulled it in that way, or supply the
referenced functions with intrinsics. Discovered the issue
trying to build libopusfile against the uninstalled static
libopus, which unlike opus-tools, doesn't itself need libm.

The -lm argument is only added to Libs for the floating-
point (default) build. It's not necessary for the fixed-
point build.

Also mark which build was used in the .pc file description.

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.