Re: [NEW] textproc/lucene++

Landry Breuil <landry@openbsd.org> writes:

> On Thu, Jun 25, 2020 at 06:08:56PM +0200, Omar Polo wrote:
>>
>> Hello there!
>>
>> Attached the port for Lucene++, a port of the java lucene library. It's
>> required by newer version of devel/poedit.
>>
>> The patches against the three CMakefiles are to disable cotire, as it
>> breaks the build. The patch against VariantUtils.h is to support newer
>> version of boost. These patches are heavily inspired (read: copied)
>> from the freebsd port.
>>
>> I'm not sure about the two patches against the .pc files, because by
>> default it generates something like
>>
>> Libs: -L/usr/local//usr/local/lib
>>
>> which is broken. Comments appreciated.
>
> i had a look, and its indeed a bit strange - your fix makes sense but
> why not consistently using LIB_DESTINATION in the patches ?

I'm not entirely sure I've understand correctly what you mean, but I've
changed that. I've killed the libdir variable and set

Libs: -L@LIBDESTINATION@ -l${lib}

> what's breaking with cotire ? care to add comments in the patches
> explaining the failures ?

yeah, I should have done so. There seems to be some incompatibility
between cotire and the c++ stdlib. This commit[0] from the freebsd port
tree says that's from libc++ 3.8.0 onwards.

This is an excerpt from the first failure:

FAILED: src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx.pch
cd /usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/src/contrib && /usr/local/bin/cmake -DCOTIRE_BUILD_TYPE:STRING=Release -P /usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/cmake/cotire.cmake precompile /usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/lucene++-contrib_CXX_cotire.cmake /usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx /usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx.pch /usr/ports/pobj/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp
In file included from /usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx:4:
In file included from /usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/src/contrib/cotire/lucene++-contrib_CXX_prefix.cxx:6:
/usr/include/c++/v1/wchar.h:137:77: error: use of undeclared identifier 'wcschr'
wchar_t* __libcpp_wcschr(const wchar_t* __s, wchar_t __c) {return (wchar_t*)wcschr(__s, __c);}
^
/usr/include/c++/v1/wchar.h:144:87: error: use of undeclared identifier 'wcspbrk'
wchar_t* __libcpp_wcspbrk(const wchar_t* __s1, const wchar_t* __s2) {return (wchar_t*)wcspbrk(__s1, __s2);}
^
/usr/include/c++/v1/wchar.h:151:78: error: use of undeclared identifier 'wcsrchr'; did you mean 'wcschr'?
wchar_t* __libcpp_wcsrchr(const wchar_t* __s, wchar_t __c) {return (wchar_t*)wcsrchr(__s, __c);}
^
[...]

and thats is followed by similar errors with various wchar functions
(wcsstr, wmemmove, wmemcpy, ...)

This, plus the fact that cotire itself is deprecated was the reason I
didn't even try to fix it. from cotire readme[1]:

The functionality provided by cotire has been superseded by
features added to CMake 3.16. Support for pre-compiling and
unity builds is now built into CMake. Thus, there will not be
any further updates or support for this project.

I've added a comment in the patches, do you think it's clear enough?
I'm not too sure about the wording:

disable cotire as it's deprecated and breaks the build with
newer libc++

[0]: https://svnweb.freebsd.org/ports?view=revision&revision=414441
[1]: https://github.com/sakra/cotire

>> It builds on amd64, passes make port-lib-depends-check and portcheck.
>>
>> NO_TEST is Yes because the port doesn't contain tests, is it right?
>
> There are tests in src/test, using a bundled copy of gtest (that should
> be patched to use the gtest from the ports, which should be added as a
> build/test dependency i think).
>
> granted, if i uncomment NO_TEST, it defaults to use ctest from cmake
> which doesnt find any tests.
> /usr/ports/mystuff/textproc/luceneplusplus/ $make test
> ===> Regression tests for luceneplusplus-3.0.7
> [0/1] cd /usr/obj/ports/luceneplusplus-3.0.7/build-amd64 && /usr/local/bin/ctest --force-new-ctest-process --exclude-regex "CMake.FileDownload|CTestTestUpload|RunCMake.ctest_submit"
> Test project /usr/obj/ports/luceneplusplus-3.0.7/build-amd64
> No tests were found!!!
>
> But README.rst points at lucene++-tester in the build dir, which indeed
> runs some unit testing:

I totally missed that part of the readme and stopped at 'No test were
found!!!'. The new tarball enables tests and add devel/gtests as
BUILD_DEPENDS, since that binary is generated during the build.

It seems that now it picks up gtest:

$ ldd lucene++-tester | grep libgtest
000003b213cf7000 000003b213d53000 rlib 0 1 0 /usr/local/lib/libgtest.so.1.0

unfortunately, after a while it core dumps:

...
[----------] 102 tests from IndexWriterTest
[ RUN ] IndexWriterTest.testDocCount
[ OK ] IndexWriterTest.testDocCount (7 ms)
[ RUN ] IndexWriterTest.testAddIndexOnDiskFull
Segmentation fault (core dumped)
*** Error 139 in . (Makefile:35 'do-test')
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2951 '/usr/ports/pobj/luceneplusplus-3.0.7/build-amd64/.test_done': @cd /usr/port...)
*** Error 2 in /usr/ports/textproc/luceneplusplus (/usr/ports/infrastructure/mk/bsd.port.mk:2581 'test': @lock=luceneplusplus-3.0.7; export...)

> /usr/obj/ports/luceneplusplus-3.0.7/LucenePlusPlus-rel_3.0.7/$ ../build-amd64/src/test/lucene++-tester
> [==========] Running 1472 tests from 201 test cases.
> [----------] Global test environment set-up.
> [----------] 1 test from VersionTest
> [ RUN ] VersionTest.testVersion
> [ OK ] VersionTest.testVersion (1 ms)
> [----------] 1 test from VersionTest (1 ms total)
> ...
>
> so maybe you need a do-test target running this binary from ${WRKBUILD}
>
> Landry

Thanks for looking into this. Attached new tarball with the mentioned
edits.