We depend on pkg-config, but we weren't explicitly testing for it, so
the absence of pkg-config would cause the sqlite test to fail, which
was confusing.
When the path was empty, path_push_unique would cause a training colon
to be added. This was a known issue that didn't cause any harm, but
while we're here, we'll clean this up.
sed on Mac is apparently incredibly broken and incapable of adding
newlines. `printf 'x' | sed 's/x/\n/'` results in 'n' on Mac rather
than a newline. GNU sed even in --posix mode does not agree with this
behavior. None the less, we can work around it here.
Some systems don't have the pkg-config file, or don't have it in the
right place. Breaking build on those systems does have the positive
effect of getting people to file bugs with those distros, but we
should at least keep things working on Debian wheezy while getting
Debian to accept the fix to ldns.
This library is used only by mod_enum and is available on most
platforms. The version in our tree has many code quality problems
that are generating noise when doing static analysis. Suffice it to
say we want rid of it as our responsibility.
FS-353
Tested with several libmemcached versions between 0.31 and
1.0.18. Unfortunately the API is extremely volatile and awkward to
use. Packaging scripts still need addressing.
FS-353
Since libedit originates from NetBSD, this and other BSDs use the
official version while Linux distributions tend to use the
autotoolized fork. The official version does not install a .pc file so
we cannot rely exclusively on pkg-config for detection.
FS-6408
Signed-off-by: Travis Cross <tc@traviscross.com>
Previously we enabled libedit support opportunistically if it was
neither enabled nor disabled explicitly. But this can result in
people being confused by libedit features not being available when
they really just need to install dependencies. With this change,
we'll break on configure if libedit-dev isn't there. If the user
really wants to build without libedit they just need to explicitly
disable it.
Cc: Ken Rice <krice@freeswitch.org>
We consider mod_spidermonkey to be completely replaced by mod_v8 (and
more generally by mod_lua) at this point. We've barely supported
mod_spidermonkey for years. Everyone should stop using it.
We're keeping this around for awhile in case people are relying on C
extensions to mod_spidermonkey and need time to migrate. This module
may or may not be part of a v1.4 release depending on whether we find
anyone cares. It definitely will not be part of the next release
after v1.4.
...at your own risk. cURL has had some serious security issues over
the years, so if you're using an ancient version, I hope that you're
receiving security patches from your vendor.
The version set here is to accommodate CentOS 6.
Travis Cross