libarchive base extraction + external JNI libraries

[benoit-pierre]

Cf. koreader/koreader-base#2088.

---

This change is 

[pazos]

Brilliant!

The example isn't that important. We can get rid of it so there's no need for buildJni logic and the jni/lzma directory.

¿?

[benoit-pierre]

If we only care about koreader's use case, we can indeed simplify a bunch of things:

• drop all submodules and jni/luajit / jni/lzma directories
• drop the old JNI build system
• remove buildJni (keep sevenZipLib for non-monolibtic mode)

[Frenzie]

I don't think we only care about KOReader's use case but generically speaking it might make more sense to use Java equivalents than to do anything along either of these lines?

[benoit-pierre]

I don't follow, Java equivalents for what?

[Frenzie]

Never mind, I forgot the logic was already largely in Java/Kotlin these days.

[pazos]

If we only care about koreader's use case, we can indeed simplify a bunch of things:

My two cents:

As far as I'm concerned I see nothing useful in this repo for usage outside KOReader.

I can see why we would want to keep it as a separate repo (ie: not merged in ko-base or koreader): it shows how we do ANativeActivity and handle the android_app_state from the "native" side.

It is a "cool project" to showcase but nobody outside KOReader can benefit from it. The sample "hello world" app I wrote a few years ago showcases why it isn't a good idea to use this repo for any android development.

The code has some assumptions that don't hold true outside koreader. Has embedded koreader logos/icons

From the technical side it is a mad usage of android_native_glue that ditches the multithread, non-blocking, capabilities of the framework by pushing everything into a single lua state.

drop all submodules and jni/luajit / jni/lzma directories

+100 for a single luajit build (syncing luajit versions between this and base is a PITA)
the same for jni/lzma. The only user is the "hello world" thingy, which is trivial and (mostly) pointless.

drop the old JNI build system
remove buildJni

Only useful for the example app?. I would say: lets get rid of it :)

tl;dr: I'm perfectly fine getting rid of unused bits and duplicated workflows. I think it is a win-win scenario.

If somebody wants to explore how thing were at some point there's a tag in place https://github.com/koreader/android-luajit-launcher/releases/tag/v2.0.0 :)

[Frenzie]

@hugleo Any thoughts one way or the other?

[hugleo]

I'm all in with @pazos . For example luajit will never be used so nobody will care to update it. Old packages will fall behind, which may become incompatible in the future especially if a compatibility patch is needed but nobody will bother to update them.