Skip to content

Commit

Permalink
Update readme (#533)
Browse files Browse the repository at this point in the history
Add disclaimer
Simplify build instructions
Remove todo because they're not to be done :)

---------

Co-authored-by: Frans de Jonge <[email protected]>
  • Loading branch information
pazos and Frenzie authored Dec 20, 2024
1 parent e3b3d3b commit 6bba3f4
Show file tree
Hide file tree
Showing 2 changed files with 15 additions and 30 deletions.
8 changes: 0 additions & 8 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -74,14 +74,6 @@ build-luajit:
cd jni/luajit && \
./mk-luajit.sh "$(ANDROID_FULL_ARCH)"

prepare: update
@echo "Building LuaJIT for all supported ABIs"
cd jni/luajit && \
./mk-luajit.sh clean && \
./mk-luajit.sh x86 && \
./mk-luajit.sh clean && \
./mk-luajit.sh armeabi-v7a

debug: update build-luajit-debug
@echo "Building $(APPNAME) debug APK: Version $(NAME), release $(VERSION), flavor $(FLAVOR)"
./gradlew -q -PversName=$(NAME) -PversCode=$(VERSION) -PprojectName=$(APPNAME) \
Expand Down
37 changes: 15 additions & 22 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,40 +19,33 @@ Have a look at KOReader's [llapp_main.lua](https://github.com/koreader/koreader/

The real starting point, called from JNI/C, is the run() function in android.lua. It sets up a few things, namely FFI definitions for the Android native API (since it uses that itself for a few things) and some wrapper functions for logging. Also, it registers the "android" module in package.loaded, so you can access it in your own code via require("android"). It also registers a new package loader which can load Lua code from the activity's asset store, so you can use require() for Lua code stored there.

## Starting
## Disclaimer

### Init and update the submodules
This repo is used as glue code to run KOReader on Android.

```sh
make update
```

### Compile LuaJIT for all target architecture(s)
Usage on its own doesn't make much sense since you're expected to write your own drawing routines in Lua!
A standalone example is attached (with no drawing routines!) in case you're curious what you'll get.

```sh
make prepare
```

## Building the example app

### Compile native code and package APK with gradle

You can see available tasks with
### Export `ANDROID_NDK_HOME`

```sh
./gradlew tasks
export ANDROID_NDK_HOME=/path/to/your/ndk/folder
```

For example, you can build the debug variant for all supported ABIs with
### Build example APK for arm 32 bits

```sh
./gradlew assembleDebug
make example
```

For more examples please look at the Makefile.

## To-do
### Build example APK for any other arch

```sh
ANDROID_ARCH=MY_ARCH make example
```

* a concept to deal with native Lua modules.
* a loader for native modules that have been put into the activity's library directory?
* a loader for obb storage, maybe? We could put native Lua modules there, for example.
* example code for framebuffer access and more
where `MY_ARCH` is either `x86`, `x86_64` or `arm64`

0 comments on commit 6bba3f4

Please sign in to comment.