Add GoogleTest infrastructure

[stweil]

Instructions (run in Tesseract source directory):

git submodule update --init googletest
mkdir demo && cd demo
cmake ..
make
bin/tesseract_test

[stweil]

Still missing:

• Update documentation.
• Add to Travis CI.
• Support for autotools (is this needed?).

That can be done as soon as there are real tests. Maybe there are also different opinions about the best location for the googletest submodule or the name of the test executable (currently tesseract_test).

configure / make is currently not used for CI tests, so maybe it is sufficient to support cmake for GoogleTest and don't implement autotools support.

[jbarlow83]

Is there a reason to have both cmake and autotools in the first place?

The homebrew build script for Tesseract uses autotools right now, so people are building with autotools. Logically one should be able to test any configuration that gets built.

I'd be tempted to deprecate/eliminate autotools so we don't have to worry about setting up test for it, if possible.

[stweil]

I personally also use mostly autotools, for example when building the installer for Windows. As far as I know it is also used by Debian based distributions when building Tesseract packages.

For the tests, having cmake in the first place seems to be sufficient for me because CI is based on that.

I'd decide later how easy or difficult it is to maintain testing with autotools.

[Shreeshrii]

I had built it locally with autotools, making changes in the makefiles etc. I think once setup the only changes will be in the makefile in the directory where the tests/test cases/test fixtures are kept. So it should not be too difficult.

https://github.com/tesseract-ocr/tesseract/blob/0f2500287a30d2b09e8c853b39913a5eb9b03ca2/unittest/Makefile

[amitdo]

Is there a reason to have both cmake and autotools in the first place?
...
I'd be tempted to deprecate/eliminate autotools so we don't have to worry about setting up test for it, if possible.

The autotools build works fine on Posix environments.

See also:
#595 (comment)

[amitdo]

2fbcba62e5e

[Shreeshrii]

Please see #1059

pull request with makefile etc

[jbreiden]

You are right Debian packaging builds Tesseract with autotools, but it would be pretty easy to switch that over to cmake if needed.

[theraysmith]

So I tried building a test using just github, and I get stuck before I can even try it.
The code doesn't build under cmake, where it does under autotools.
Since this is my first attempt at using cmake I'm probably doing something wrong, but it seems less reliable/portable than autotools so far:

~/opensrc/git/tesseract/demo$ make
[ 97%] Built target libtesseract
Linking CXX executable bin/tesseract
liblibtesseract.so.4.0.0: undefined reference to l_generateCIDataForPdf' liblibtesseract.so.4.0.0: undefined reference to l_CIDataDestroy'
liblibtesseract.so.4.0.0: undefined reference to pixReadFromMultipageTiff' liblibtesseract.so.4.0.0: undefined reference to pixReadMemFromMultipageTiff'
collect2: error: ld returned 1 exit status

It looks to me like it is picking up the wrong version of leptonica. I think these are new functions in the latest version. I built and installed the latest leptonica earlier today.
So how do I make it build under cmake? cmake fans speak up before I get turned off it completely!

[amitdo]

You should also build leptonica with CMake.

[stweil]

I noticed for the first time that cmake builds a liblibtesseract.so. That looks like a bug, because it should be libtesseract.so.

[stweil]

You should also build leptonica with CMake.

That's not strictly necessary. As long as I install it to the standard location (/usr/lib/x86_64-linux-gnu/liblept.so.5 for my Debian installation), the Leptonica library works both with CMake and autotools.

Ray, I‌ assume that your latest Leptonica was installed in /usr/local. Then CMake probably won't find it by default.

[jbarlow83]

I think the above is a case in point for my earlier comment that we should get rid of either Autotools or CMake. When there's two equivalent tools and people prefer one or the other, maintenance of one of them falls behind.

[amitdo]

Basically, CMake is for Windows&MSVC and autotools is for all other environments.
I'm talking only about this project, not about other projects' build tool usage.

Related: DanBloomberg/leptonica#253

[theraysmith]

No luck. cmake doesn't work on LInux. Even building leptonica with cmake puts the library in /usr/local, so if cmake isn't going to look there, it isn't going to find it.

…

On Fri, Aug 18, 2017 at 3:23 AM, Amit D. ***@***.***> wrote: Basically, CMake is for Windows&MSVC and autotools is for all other environment. I'm Talking only about this project, not about other projects build tool usage. Related: DanBloomberg/leptonica#253 <DanBloomberg/leptonica#253> — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1051 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL056SH7Rdi05R6Ra1KIeRINkliVA_g6ks5sZWYWgaJpZM4OhhM1> .

-- Ray.

[amitdo]

I suggest to let @egorpugin (maintainer of CMake build for both Leptonica and Tesseract) some time to response before giving up on CMake for the unit-testing.

[egorpugin]

CMake does not work properly on linux. Please, use autotools for some time.
Or is it hard to integrate tests with autotools?