Library soname versioning is something we normally change
only right before each release. However, with 1.0.2 being
released from the 1.0.x branch with 3.0.3, it makes sense
to make the same update here. That way when we do a new
release from master we can just increment again and have
the version properly reflect ranges relative to the stable
branch.
Passing 'enable' as an argument to AM_MAINTAINER_MODE flips the
default to enabled, rather than disabled until automake 1.11.
This is a safer default for a developer-oriented library.
./configure --disable-maintainer-mode is still available for
packagers who what to preserve the upstream build distribution.
On earlier automake versions, the argument appears to have no
effect, so there is no behaviour change for developers using
older autotools.
Based on a patch for opusfile by ron@debian.org.
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.
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.
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.
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.
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.
Previously the autotools build litered whatever directory
'make' was invoked from with intermediate files. Adding
'subdir-objects' to AUTOMAKE_OPTIONS tells it to put them
in subdirectories according to the relative paths to the
source files, .i.e. silk/schur.o for $(srcdir)/silk/schur.c
The change to autogen.sh is necessary to handle the
(apparently new) case where an AUTOMAKE_OPTIONS line is
given without a minimum version number.
Rather than compiling in the fixed version number from the configure
file, it's more helpful for testing and debugging to directly embed
the repository's revision. We use 'git describe --tags' for this, since
for tagged revisions it just returns the tag name, and in other cases
is more readable than a raw commit id.
If git isn't present or can't find a repository to query, we fall back
to the static version number in the configure script.
Automake version 1.11 and above provide a build mode where
each build command is replaced by a single-line annotation.
Since autotools build lines for libraries typically each fill
an entire terminal screen, this mode makes it easier to keep
track of build progress, and warnings stand out more clearly.
For debugging the build process, the old behaviour can be
recovered by running 'make V=1' at bulid time, or by passing
--disable-silent-rules to configure.
Since Automake 1.11 is still very recent, we only invoke
the AM_SILENT_RULES macro if it is defined, allowing fallback
to the old behaviour under previous versions of automake.
