Fix "'tesseract/baseapi.h' file not found"

[native-api]

Resolves #920

This pullrequest changes

• Fixes compilation error detailed below
• Renames similarly named cache entries to prevent confusion that caused this bug

Scanning dependencies of target opencv_text
[ 76%] Building CXX object modules/text/CMakeFiles/opencv_text.dir/src/erfilter.cpp.o
In file included from /Users/travis/build/skvark/opencv-python/opencv_contrib/modules/text/src/erfilter.cpp:43:
/Users/travis/build/skvark/opencv-python/opencv_contrib/modules/text/src/precomp.hpp:54:10: fatal error: 'tesseract/baseapi.h' file not found
#include <tesseract/baseapi.h>
         ^
1 error generated.
make[2]: *** [modules/text/CMakeFiles/opencv_text.dir/src/erfilter.cpp.o] Error 1
make[1]: *** [modules/text/CMakeFiles/opencv_text.dir/all] Error 2

Sample failure: https://travis-ci.org/skvark/opencv-python/jobs/510374018

CMake command line: cmake /Users/admin/Documents/opencv-python/opencv -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX:PATH=/Users/admin/Documents/opencv-python/_skbuild/macosx-10.7-x86_64-3.7/cmake-install -DPYTHON_EXECUTABLE:FILEPATH=/usr/local/opt/python/bin/python3.7 -DPYTHON_VERSION_STRING:STRING=3.7.2 -DPYTHON_INCLUDE_DIR:PATH=/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/include/python3.7m -DPYTHON_LIBRARY:FILEPATH=/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib -DSKBUILD:BOOL=TRUE -DCMAKE_MODULE_PATH:PATH=/usr/local/lib/python3.7/site-packages/skbuild/resources/cmake -DPYTHON3_EXECUTABLE=/usr/local/opt/python/bin/python3.7 -DBUILD_opencv_python3=ON -DOPENCV_SKIP_PYTHON_LOADER=ON -DOPENCV_PYTHON3_INSTALL_PATH=python -DINSTALL_CREATE_DISTRIB=ON -DBUILD_opencv_apps=OFF -DBUILD_SHARED_LIBS=OFF -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF -DBUILD_DOCS=OFF -DOPENCV_EXTRA_MODULES_PATH=/Users/admin/Documents/opencv-python/opencv_contrib/modules -DWITH_QT=4 -DWITH_LAPACK=OFF -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.7 -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_OSX_ARCHITECTURES:STRING=x86_64 -DOPENCV_CMAKE_DEBUG_MESSAGES=1

[LaurentBerger]

Thanks for update. Are you sure for leptonica : https://github.com/DanBloomberg/leptonica/blob/master/cmake/templates/LeptonicaConfig.cmake.in ?

When I build opencv with tesseract I give only leptonica lib: no need leptonica and tesseract https://github.com/tesseract-ocr/tesseract/blob/master/cmake/templates/TesseractConfig.cmake.in

see also https://docs.opencv.org/trunk/db/d4c/tutorial_install_tesseract.html

[native-api]

@LaurentBerger No, I'm not. I just renamed existing vars and didn't look any further.

I can say for sure that pkg_check_modules at https://github.com/opencv/opencv_contrib/blob/master/modules/text/cmake/FindTesseract.cmake#L3 does add both leptonica and tesseract to CFLAGS (an excerpt from CMakeCache.txt):

Tesseract_CFLAGS:INTERNAL=-I/usr/local/Cellar/tesseract/4.0.0_1/include;-I/usr/local/Cellar/leptonica/1.78.0/include/leptonica
Tesseract_CFLAGS_I:INTERNAL=
Tesseract_CFLAGS_OTHER:INTERNAL=
Tesseract_FOUND:INTERNAL=1
Tesseract_INCLUDEDIR:INTERNAL=
Tesseract_INCLUDE_DIRS:INTERNAL=/usr/local/Cellar/tesseract/4.0.0_1/include;/usr/local/Cellar/leptonica/1.78.0/include/leptonica
Tesseract_LDFLAGS:INTERNAL=-L/usr/local/Cellar/tesseract/4.0.0_1/lib;-L/usr/local/Cellar/leptonica/1.78.0/lib;-ltesseract;-llept
Tesseract_LDFLAGS_OTHER:INTERNAL=
Tesseract_LIBDIR:INTERNAL=
Tesseract_LIBRARIES:INTERNAL=tesseract;lept
Tesseract_LIBRARY_DIRS:INTERNAL=/usr/local/Cellar/tesseract/4.0.0_1/lib;/usr/local/Cellar/leptonica/1.78.0/lib

[alalek]

Only change with ocv_include_directories() looks good.
Other changes seems to do "nothing" (have no effect, except names renames).

As a "bugfix" this patch should go into 3.4 branch first. We will merge changes from 3.4 into master regularly (weekly/bi-weekly).

So, please:

• change "base" branch of this PR: master => 3.4 (use "Edit" button near PR title)
• rebase your commits from master onto 3.4 branch. For example:
  git rebase -i --onto upstream/3.4 upstream/master
  (check list of your commits, save and quit (Esc + "wq" + Enter)
  where upstream is configured by following this GitHub guide and fetched (git fetch upstream).
• push rebased commits into source branch of your fork (with --force option)

Note: no needs to re-open PR, apply changes "inplace".

[alalek]

This change is wrong.

[native-api]

Could you elaborate?

The idea is to avoid having both Tesseract_INCLUDE_DIR and Tesseract_INCLUDE_DIRS in the global namespace -- because confusing them is what I presume caused this bug in the first place. (Same for _LIBRARY vs _LIBRARIES.)

So to "have no effect, except names renames" is the intent.

[alalek]

find_path() always find one entry. DIRS is plural noun.

find_path(Tesseract_INCLUDE_DIR ...)  # this goes into CMake cache and can be changed by user

set(Tesseract_INCLUDE_DIRS "${Tesseract_INCLUDE_DIR}" "${OtherDependency_INCLUDE_DIR}")  # DIRs variant (should not be cached)


# Usage
ocv_include_directories(${Tesseract_INCLUDE_DIRS})

[alalek]

The same story is about find_library() / LIBRARY / LIBRARIES.

[native-api]

So what if it finds one entry? We start with one, then add more further in the code if needed.

A more convincing argument is that there is a bug in my logic: if we take the value of a cache entry and add more stuff to it, that stuff will be added again on subsequent runs!

I considered unset()'ing Tesseract_INCLUDE_DIR et al. instead but this would cause it to be re-detected on each run.

I would still like to make the names more distinct this way or another and suggest that Tesseract_INCLUDE_DIR is not supposed to be used. I can't find any naming conventions for CMake for "private" cache entries (names starting with underscore that are typically used for this seem to rather be reserved for CMake's internal use here).

[native-api]

Since the primary bug is already fixed, this is going to be done in a separate PR though.

[alalek]

Variables in find_path()/find_library()/etc:

• may contain one path or "NOT_FOUND".
• values are cached between CMake runs (do not searching again and again).

unset()'ing Tesseract_INCLUDE_DIR

Bad idea.
This blocks used to specify own path via command-line if auto-detection doesn't work properly (some new paths to check or custom location of dependency).

[native-api]

@alalek it turns out, this bug has already been fixed in fdb575d which is not in 4.0.1.
I've no idea why it applied successfully onto master which is supposed to also have that commit...