| | <<<Back 1 day (to 2017/05/07) | 20170508 |
| tor8 | Robin_Watts: on mac, the more specific makefile rules didn't apply if they came after the more generic rules | 10:36.47 |
| | that might be true on linux too, but possibly masked by system headers | 10:36.57 |
| | moving the generic rules to after the specific ones fixed the problem | 10:37.17 |
| | Robin_Watts: you're right about throwing in fz_walk_path, I've reworked a commit, on tor/master now | 10:38.20 |
| Robin_Watts | Ta. | 10:38.31 |
| | tor8: all seem fine to me. Are you going to squash those 2 together ? | 11:32.08 |
| tor8 | Robin_Watts: sure, I can do that | 11:33.53 |
| Robin_Watts | tor8: mupdf commits are borked according to the cluster. | 12:17.39 |
| tor8 | Robin_Watts: gah! | 12:20.12 |
| | Robin_Watts: force push? | 12:21.23 |
| | Robin_Watts: I've reverted. can you prod the cluster? | 12:23.30 |
| Robin_Watts | Done. | 12:25.09 |
| sebras | tor8: two commits on sebras/master | 13:04.15 |
| tor8 | first one LGTM | 13:05.34 |
| | second one adds a couple of files it probably shouldn't | 13:05.45 |
| sebras | does it? | 13:05.49 |
| | oh. | 13:05.51 |
| | I wonder how the cluster files ended up in a commit. | 13:06.18 |
| | tor8: updated. | 13:07.05 |
| | and now I fixed the typo in the commit message. | 13:07.53 |
| tor8 | sebras: LGTM | 13:12.24 |
| sebras | tor8: I just retested -old:sebras/master | 13:42.37 |
| | and it builds fine with the gradle.properties.sample renamed to gradle.properties both using gradlew and android studio | 13:43.03 |
| | note that if I don't copy the gradle.properties it will not compile problem free. | 13:43.34 |
| tor8 | sebras: please don't remove the 'release.sh' script | 13:56.26 |
| | not without replacing it with something equivalent | 13:56.42 |
| | sebras: I've got the incantation in build.gradle to sign the apk for release builds | 13:57.00 |
| | sebras: on -old:tor/jni | 13:57.28 |
| sebras | I did anticipate that you'd say that but I didn't know what to replace it with. :) | 14:00.37 |
| | btw, building draw-device.c fails for me with "fatal error: error in backend: Undefined temporary symbol" but only if I have NDK_DEBUG=1 which causes -O0, not when I have NDK_DEBUG=0 which uses -O2 | 14:01.29 |
| tor8 | lovely | 14:01.53 |
| sebras | so it seems like a compile issue that might be resolved in the next NDK, and I don't think we worry about mips so much. | 14:01.58 |
| | tor8: I had gradle print the ndk-build command and then I used V=1 to see what command failed and found someone to stated that it was due to the value of NDK_DEBUG and this info was accurate. | 14:02.45 |
| | tor8: I'm not sure how to handle that other than to ignore it (seems to work if you build from inside android studio I think (not sure why)). | 14:03.13 |
| | tor8: I merged your commit for the release things into the "switch build system one" to make it a single step that just works and then some polishing commits after that. | 14:05.10 |
| tor8 | sebras: beware though, that the JNI branch of -old still has a lot of stuff that isn't implemented yet | 14:13.17 |
| | proofing, forms, javascript alerts, etc. | 14:14.49 |
| | those features are missing from the current JNI bindings, and I still need to revise the C api before deciding on the form the JNI api will have | 14:16.19 |
| | so it may make sense to backport the gradle stuff to the master branch | 14:16.42 |
| sebras | tor8: sure, I just cherry-picked your patch ec15a9d | 14:20.41 |
| | git diff 5f72e0d..c361d22 proves this. | 14:21.02 |
| tor8 | sebras: jniLibs.srcDir 'libs' is not necessary | 14:29.58 |
| | jni.srcDirs = [] // This prevents the auto generation of Android.mk also seems unnecessary according to my tests | 14:31.35 |
| | minSdkVersion, targetSdkVersion, versionCode, versionName should match the entries in AndroidManifest.xml no? | 14:34.19 |
| sebras | tor8: would I be able to use @string/version in the build.gradle file? | 14:37.37 |
| | tor8: for verisonName, that doesn't look reasonable to me. | 14:37.50 |
| | I wonder how the values in build.gradle relate to those in AndroidManifest.xml | 14:38.25 |
| tor8 | I wonder if we can elide the entries altogether | 14:38.41 |
| | I don't know gradle well enough to tell | 14:39.00 |
| sebras | tor8: http://stackoverflow.com/questions/19997509/android-studio-why-are-minsdkversion-and-targetsdkversion-specified-both-in-and | 14:40.15 |
| | tor8: seems like build.gradle is an override mechanism. but AndroidManifest.xml is used by google play. | 14:43.06 |
| | in that case I'd like to try without it in build.gradle as it seems to be _just_ the overrid mechanism and we _need_ AndroidManifest.xml | 14:43.32 |
| tor8 | sebras: yes. | 14:55.29 |
| sebras | tor8: I broke something, now it doesn't build... clean... rebuild. *sigh* | 14:58.50 |
| | feels like having to reboot your computer because one program crashed. :-/ | 14:59.05 |
| | tor8 (for the logs): I finally figured out what the problem was and how to circumvent it: the signing should be optional and the changes you introduced in build.gradle are not optional (albeit the values you supply through gradle.properties are). | 17:11.36 |
| | tor8 (for the logs): I added a check for the properties in gradle.properties and skips the signing if those properties are not present. | 17:12.17 |
| | this is now on -old:sebras/master | 17:12.26 |
| | Forward 1 day (to 2017/05/09)>>> | |
Log of #mupdf at irc.freenode.net.