Landry Breuil <[email protected]> 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.
luceneplusplus.tar.gz
Description: Binary data
