• https://oligarchy.co.uk/xapian/1.4.18/ (Download)

• (2021-02-07) Updated to version: xapian-bindings-1.4.18
• (2020-12-21) Updated to version: xapian-bindings-1.4.17
• (2020-07-26) Updated to version: xapian-bindings-1.4.16
• (2020-03-05) Updated to version: xapian-bindings-1.4.15
• (2019-12-29) Updated to version: xapian-bindings-1.4.14
• (2019-10-23) Updated to version: xapian-bindings-1.4.13
• (2017-11-14) Updated to version: xapian-bindings-1.4.5
• (2015-04-06) Package added to openports.se, version xapian-bindings-1.2.15 (created)

Log message:
Switch default ruby version to 3.0
Add patches to a few ports to build with ruby 3.0, mostly -fdeclspec to
CFLAGS or CXXFLAGS.
Bump ports where the default version change causes a package change.
OK kmos@

Log message:
update py-sphinx to 4.0.2 and regen PLISTs for affected consumers
all consumers were packaged and installed on amd64 by me; all python2
syntax in consumers appears to have been updated at this point making
it possible to move to the 4.x series.
lang/ghc bits look ok to gnezdo@
ok sthen@ on the rest

Log message:
Reverse the polarity of MODPY_VERSION; default is now 3.x,
if a port needs 2.x then set MODPY_VERSION=${MODPY_DEFAULT_VERSION_2}.
This commit doesn't change any versions currently used; it may be that
some ports have MODPY_DEFAULT_VERSION_2 but don't require it, those
should be cleaned up in the course of updating ports where possible.
Python module ports providing py3-* packages should still use
FLAVOR=python3 so that we don't have a mixture of dependencies some
using ${MODPY_FLAVOR} and others not.

Log message:
adapt to py-sphinx-3.5.1

Log message:
update the xapian ports to 1.4.18, from Lucas Raab

Log message:
regen PLISTs for python ports with .so files that end up renamed due to
the EXT_SUFFIX change in Python 3.8.7

Log message:
xapian-bindings tweaks:
- don't try to link -lstdc++ (hardcoded) which was done specially by
upstream "We need to explicitly link against -lstdc++ on OpenBSD
discovered on OpenBSD 3.7 with GCC 3.3.5 but this appears to
be due to a deliberate decision on the part of OpenBSD developers"
- use gnu libtool, base libtool doesn't support -shrext which breaks
things for python 3.8.7+ which uses an abi prefix for .so files
- regen patches

Log message:
update to xapian 1.4.17, switch from libuuid to libc functions while there
(both are supported but xapian prefers libuuid if found during configure).
WANTLIB syncs in dependent ports to follow.

Log message:
update py-sphinx to 1.5.6
main changes are:
- add a new dep on py-requests
- undo the no longer needed iftex.sty workaround
- move MODPY variables to more standard location
- regen plist
Unfortunately py-sphinx changed the suffix from .txt to .rst.txt in the
1.5 series. This means we have to update PLISTs for about 20+ ports as
a result of this version update. Hopefully future updates of py-sphinx
won't be quite as involved.
ok sthen@

Log message:
update xapian to 1.4.16, from Lucas Raab, tweaks: I didn't take the
SHARED_LIBS bump because there's no apparent reason for doing so, and
remove a REVISION from -bindings.

Log message:
bump REVISION; python 3 default changed to 3.8

Log message:
update the xapian-* ports to 1.4.15, from Lucas Raab.
Includes a bodge to avoid an autoconf namespace problem that has since
been fixed upstream, I added a comment reminding to remove it after the
port is next updated.

Log message:
update to xapian 1.4.14

Log message:
update to xapian 1.4.13
mostly from Lucas Raab, patch/wantlib regen + shared_libs bump from me

Log message:
Fix xapian ruby bindings after Ruby security update

Log message:
Fix xapian ruby binding after recent ruby update
Problem found the hard way by naddy@

Log message:
replace simple PERMIT_PACKAGE_CDROM=Yes with PERMIT_PACKAGE=Yes

Log message:
bump all the py3 things, _SYSTEM_VERSION didn't quite work out how
we expected and it's easier|safer to do it this way than fiddle with
pkg_add now. thanks aja for update tests with a quick bulk.

Log message:
Missed bump for the ruby subpackage PLIST change.

Log message:
Use python3 FLAVOR for dependencies.
ok robert@

Log message:
move the python subpackage to python 3 as this is only used
by kopano which is using python 3 already
update plist of the ruby subpackage while here

Log message:
Move xapian homepage/master_sites to https.

Log message:
Only add ruby or python RDEPs to the ruby and python subpackages.
Add explicit python RDEP to python subpackage.
Feedback from ajacoutot@

Log message:
Add COMPILER lines to c++ ports which currently use the default. Adjust
some existing COMPILER lines with arch restrictions etc. In the usual
case this is now using "COMPILER = base-clang ports-gcc base-gcc" on
ports with c++ libraries in WANTLIB.
This is basically intended to be a noop on architectures using clang
as the system compiler, but help with other architectures where we
currently have many ports knocked out due to building with an unsuitable
compiler -
- some ports require c++11/newer so the GCC version in base that is used
on these archirtectures is too old.
- some ports have conflicts where an executable is built with one compiler
(e.g. gcc from base) but a library dependency is built with a different
one (e.g. gcc from ports), resulted in mixing incompatible libraries in the
same address space.
devel/gmp is intentionally skipped as it's on the path to building gcc -
the c++ library there is unused in ports (and not built by default upstream)
so intending to disable building gmpcxx in a future commit.

Log message:
Allow building with ruby 2.5
Remove RDocs from PLIST since different files are generated on ruby 2.5.

Log message:
bump LIBCXX/LIBECXX/COMPILER_LIBCXX ports.

Log message:
add pthread to COMPILER_LIBCXX.
white lie, but it allows clang and gcc to be more similar
bump accordingly.

Log message:
use COMPILER_LIBCXX where applicable

Log message:
use LIBCXX

Log message:
Add perl to WANTLIB, first batch. This used to be done automatically but
since SHARED_ONLY support was removed across the ports tree the perl module
no longer adds it, so it must be done manually for any perl ports that
provide perl shared-library modules (i.e. libdata/perl5/site_perl/$ARCH/*.so)
and you must not remove them from WANTLIB even if they show as "Extra".