I can completely understand the reasons and need for the way tess-two does things. If I was working with Android Studio and Java/Kotlin, I would probably never have spend time on this. Last time I used tess-two it worked flawlessly.
I am coming at this from the perspective of Qt projects however. That means I'm already in C++ land for the most part, which also means, that I have a preference towards including and/or building libraries in a more traditional way. The debugging aspect is probably not as nice as with Android Studio integrations, but I don't strip debug symbols by default in my builds, so using gdb or lldb should work without further ado. /René On Wed, 31 Jul 2019 at 18:31, Alex Cohn <[email protected]> wrote: > Hi René, > > thanks for your detailed post. > > Let me try to explain why I prefer to use NDK 'directly'. > > When we need some libraries (like *libtess*) as parts of our apps, we > need the library integrated into the app. Often, the library comes with JNI > layer and can be accessed (inderectly) from the app Java/Kotlin code. Such > setup requires building libtess with extra C++ classes that are not present > in https://github.com/tesseract-ocr/tesseract repository. They only exist > in https://github.com/rmtheis/tess-two repository and its forks. Also, > this requires building the Java/Kotlin side of the JNI wrapper, which needs > Android SDK, not only NDK. > > An alternative approach is to consume *libtess* in a C++ library that is > used by app Java code. This time, we need NDK to be integrated into Android > Studio. Actually, we always want NDK to be integrated into Android Studio, > because this is not only a build environment, it's a debug environment, > too. Android Studio 3.2 and higher allows to step through Java code into > C++ code, and back. To set breakpoints in both Java and C++, and so on. > > A library that is compiled externally, like in docker, is harder to debug. > I agree that for some libraries, in some cases, the hardship of building it > properly outweighs the hardship of debugging it. But here and now, building > libtess – both *static *library that can be seamlessly linked into your > own C++ library, and as *shared* library that can be called through JNI > from the app – is easy and even quite quick. > > As for your complaint about keeping multiple versions of Android NDK for > compatibility purposes, I beg to differ. The NDK team does a very good job > of maintaining backwards compatibility, so there is no added value in using > older NDK releases (as long as you can master the build process to fit the > latest and greatest NDK release). That's what I took care of in my fork > https://github.com/alexcohn/tess-two and now you don't need NDK r16 build > anymore. I dare say, still using NDK r16 these days is unjustified. It has > known runtime bugs, e.g. with crash reports for arm64, and may be > considered a security risk. > > Best Regards, > Alex > > -- > You received this message because you are subscribed to the Google Groups > "tesseract-ocr" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tesseract-ocr/8d3177df-2fab-4eb7-a4e6-6f87da926dc8%40googlegroups.com > <https://groups.google.com/d/msgid/tesseract-ocr/8d3177df-2fab-4eb7-a4e6-6f87da926dc8%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Never fear, Linux is here. -- You received this message because you are subscribed to the Google Groups "tesseract-ocr" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/CAB-60nibMUwn8K6t5-E%2B7vzDOCgNNmiK-JFWK688sYAUyemD%2BQ%40mail.gmail.com.
