Our main version string is designed for release engineering purposes:
it matches file name conventions used for versioned tarballs and the
versions sort lexicographically while containing all pertinent
information.
With this commit we add in parentheses a more human-friendly rendering
of the version string: we spell out the meaning of each field and
render the datetime in RFC 822 notation.
sed: 1: "/#define *SWITCH_VERSIO ...": bad flag in substitute command: '}'
Reported-by: scruz in #freeswitch @ irc.freenode.net
Signed-off-by: Stefan Knoblich <s.knoblich@axsentis.de>
This amends commit f8be71ac6d.
This still should resolve FS-4303.
What's going on here is that we need a portable way to access
strftime. date(1posix) doesn't provide enough. And without perl, I
can't think of a better way to get to it than just using C. So the
logic for generating the extended revision has been moved into a small
self-contained and hopefully portable C program.
The revision was no longer picking up the last git commit. Instead,
it was showing the last release. This commit appends the last git
commit hash to the last release if a git repository is available.
Further, it checks whether there are uncommitted changes in the git
repository and adds an unclean tag to the version if this is the case.
Note that currently this will append the git commit hash even on a
tagged release if built directly from a git repository. Perhaps this
isn't such a bad thing, but if it turns out not to be desired, I have
an idea on how to squelch this without making unwarranted assumptions
about the remote layout of someone's local repository.
This workaround makes the build work exactly as it did when libzrtp
was installed as a system library. By default gcc ignores warnings
caused by system headers, so for the moment we'll continue to pretend
that libzrtp headers come from the system.
OK, libtool pulling in all depdencies doesn't work (*sigh*)
so add CORE_LIBS back to _LDADD and also add ODBC_LIB_FLAGS (conditionally).
Tested on Debian Squeeze (6.0.x) amd64 (libtool-2.2.6), where
everything seems to be falling apart easily.
There's still a lot of room for improvement, though. Bundled libs are making
this harder, as we don't have a sane way to get their dependency libs and
libtool drops them on the floor, even if they are in the .la-file's dependency
list (e.g. mod_spandsp using libtiff(.la), which needs libjpeg).
( reference: http://www.gnu.org/s/hello/manual/libtool/Inter_002dlibrary-dependencies.html ).
Let's see what i did break this time...
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
This fixes the linking order problems reported in FS-3638.
Clean up libfreeswitch dependency handling:
PLATFORM_CORE_LDFLAGS - Non-library linker flags, specific to this platform
PLATFORM_CORE_LIBS - Library flags/libraries need to build libfreeswitch on this platform
Drop LDADD dependencies from tone2wav and fs_encode, except for libfreeswitch.la, which will
"automagically" pull in all other libraries, now that we fixed libfreeswitch.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
The latter is a well known automake variable, used
to set (per-Makefile) automake options and supported
since the beginning of time (= automake 1.4).
The former is a made-up variable that doesn't really
do anything.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
Default behaviour is unchanged.
Packagers should use this option to install freeswitch.pc into
the system's main pkg-config directory (e.g. /usr/lib/pkgconfig).
Signed-off-by: Stefan Knoblich <s.knoblich@axsentis.de>
Tested-by: Stefan Knoblich <s.knoblich@axsentis.de>
"LIBS" in the final fsxs script will be empty now.
We still link against libfreeswitch when building a module,
but we don't explicitly list (some of) its dependency libs anymore
(this list was not complete anyway).
This fixes a bogus /path_to_source/expat.la entry in LIBS that
came from "apu-config --libs".
Tested on Gentoo x86_64 (binutils 2.20.1) and Centos 5.5 (binutils 2.17.50).
Tested-by: Stefan Knoblich <s.knoblich@axsentis.de>
Signed-off-by: Stefan Knoblich <s.knoblich@axsentis.de>
