On Tuesday, 31 December 2019 at 03:59:58 UTC, Adam D. Ruppe wrote:
> On Wednesday, 18 December 2019 at 15:53:14 UTC, kinke wrote:
>> Heh, it looks like the Wiki page (https://wiki.dlang.org/Cross-compiling_with_LDC - I've added an exemplary Android section there as well, using `-gcc` to specify the NDK's preconfigured clang) needs some overhaul then if not even you guys seem to find the relevant information.
>
>
> Well, I worked this into my setup program. It changes ldc2.conf so then you can just
>
>         dub build --compiler=ldc2 -a i386-none-linux-android
>         @mv libdubtest.so BasicActivity/app/src/main/jniLibs/x86 || true
>         #
>         dub build --compiler=ldc2 -a armv7a-none-linux-android
>         @mv libdubtest.so BasicActivity/app/src/main/jniLibs/armeabi-v7a || true
>         #
>         dub build --compiler=ldc2 -a x86_64-none-linux-android
>         @mv libdubtest.so BasicActivity/app/src/main/jniLibs/x86_64 || true
>         #
>         dub build --compiler=ldc2 -a aarch64-none-linux-android
>         @mv libdubtest.so BasicActivity/app/src/main/jniLibs/arm64-v8a || true
>
> I really wish dub had a way to specify the output directory on its command line which would eliminate the need for those ugly mv commands :(
>
> but meh now it works without the helper programs - just a setup step.
>
>
>
> Meanwhile, I wrote a class/jar -> D interface converter and it works beautifully. Alas, dmd is giving me "forward reference" errors in there :(
>
> so the crtp trick is triggering a bunch of internal compiler bugs.
>
> ugh.

I have to check in detail if I can find some free time, but maybe in dub.json of d_android a postGenerateCommands line could be defined which calls a dub single package responsible for copying the binary to the right place depending on the actual architecture.

"preGenerateCommands": ["$DUB copy.d"]

Inside of the coding of copy.d all needed information can be retrieved from environment variables (see list of environment variables here https://dub.pm/package-format-json.html#environment-variables).

Kind regards
Andre

On Monday, 16 December 2019 at 21:37:51 UTC, Adam D. Ruppe wrote:
> I'm gonna drop the link here without further comment:
>
> https://github.com/adamdruppe/d_android
>
> hopefully I've written enough in the repo so anyone who wants to play with it can... and if not, I need to fix the docs :)
>
> let me know if you find any success or failure playing with it.


Thank you very much, Sir
i managed to run the test app on my phone via Android Studio :))

https://framapic.org/JHDQ9v9AnsXj/XOscSF4YieDR.png

On Wednesday, 1 January 2020 at 12:44:30 UTC, visitor wrote:
> i managed to run the test app on my phone via Android Studio :))

Nice! I just realized that I forgot to commit some of the files so cool that you got it working despite me :)

Another big update here in my blog this week:

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html

On Wednesday, 1 January 2020 at 16:48:40 UTC, Adam D. Ruppe wrote:
> Another big update here in my blog this week:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_30.html

A question that comes to mind with respect to your JNI work: Is this specific to Android, or could we use it, for instance, as a way to call Java functions from R, where we use D as a bridge to simplify things? If so, this could potentially lead to significant use of D, as there are a fair number of R packages that call into Java. It was a nightmare when I looked into it years ago. Making this even more appealing is GDC's inclusion in GCC.

On Wednesday, 1 January 2020 at 16:48:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 January 2020 at 12:44:30 UTC, visitor wrote:
>> i managed to run the test app on my phone via Android Studio :))
>
> Nice! I just realized that I forgot to commit some of the files so cool that you got it working despite me :)

indeed :))
so to reply : i fortunately had a bit of (very recent) understanding about D/Android setup and stumbling upon the link crash without main() i figured that the main() hack was part of the missing files ... i went, like that, by guess and trial filling the holes :))

As for the second hack which caused me problems too, obviously, i found that if i put the D classes inheriting from your JavaClass each in their own files the problem disappears ...
everything compiles and run !
(i have a bunch of "R_ARM_TLS_LDO32 used with non-TLS symbol" warnings, though, at link time ... - i compile for armv7a only - )

Btw, with your work i can launch and work from D with libreoffice documents !
The exercice is silly because i use D to manipulate java to drive uno code (and probably C++)  but it works ! :))  (i will try to use your createJVM setup when i have time)

On Wednesday, 1 January 2020 at 17:12:01 UTC, bachmeier wrote:
> A question that comes to mind with respect to your JNI work: Is this specific to Android, or could we use it, for instance, as a way to call Java functions from R, where we use D as a bridge to simplify things?

That should be possible. And the bindings generator and packing techniques should work on other things too. All I did here was run it on android.jar, but I see no reason why it wouldn't work on other jars too, perhaps with adjustments for like java.lang.X so it pulls them from another source if necessary.

The jni thing is not specific to Android at all (which is also why I put it in my arsd repo instead of the d_android one). In fact, most my testing of it has been done outside android since it is so much more convenient. I have tested on 64 bit Windows and 64 bit Linux as well, it should work anywhere else D and the jvm both run.

On Wednesday, 1 January 2020 at 17:35:28 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 January 2020 at 17:12:01 UTC, bachmeier wrote:
>> A question that comes to mind with respect to your JNI work: Is this specific to Android, or could we use it, for instance, as a way to call Java functions from R, where we use D as a bridge to simplify things?
>
> That should be possible. And the bindings generator and packing techniques should work on other things too. All I did here was run it on android.jar, but I see no reason why it wouldn't work on other jars too, perhaps with adjustments for like java.lang.X so it pulls them from another source if necessary.
>
> The jni thing is not specific to Android at all (which is also why I put it in my arsd repo instead of the d_android one). In fact, most my testing of it has been done outside android since it is so much more convenient. I have tested on 64 bit Windows and 64 bit Linux as well, it should work anywhere else D and the jvm both run.

Excellent. I'll definitely be digging into this when I have time. R is very heavily used. Once users have D installed to facilitate calling into Java, there's no longer a good reason to not work with D itself.

On Wednesday, 1 January 2020 at 17:16:19 UTC, visitor wrote:
> so to reply : i fortunately had a bit of (very recent) understanding about D/Android setup and stumbling upon the link crash without main() i figured that the main() hack was part of the missing files ... i went, like that, by guess and trial filling the holes :))

nice!

That's a big reason why I am trying to explain the principles behind each step too, exactly so other people can fill in when I screw it up. And I might not maintain everything into all future versions too (I don't really use mobile myself and the hardware I own is already 5ish years old so I'm not likely to follow bleeding edge SDKs anyway) but as long as the principles still apply it will be easy for someone else to pick it up and keep it going.

> (i have a bunch of "R_ARM_TLS_LDO32 used with non-TLS symbol" warnings, though, at link time ... - i compile for armv7a only - )

Yeah, I see those too, it seems to come out of the upstream ldc builds... but also don't appear to matter. Doesn't happen on the other targets btw.

> Btw, with your work i can launch and work from D with libreoffice documents !
> The exercice is silly because i use D to manipulate java to drive uno code (and probably C++)  but it works ! :))  (i will try to use your createJVM setup when i have time)

oh interesting, I didn't even realize that could be an application at all!

But Java is a pretty big world and D works pretty nicely with it so there is sure to be many things I didn't even think of.

i just need to write up the rest of the documentation so people can use it without having to follow my crazy thoughts as they jump around. but today my wrist is sore so taking it easy the rest of the day prolly. that blog took a lot of write up.

On Wednesday, 1 January 2020 at 17:35:28 UTC, Adam D. Ruppe wrote:
> bindings generator

oh one thing I forgot to mention on this is that right now it generates interfaces, but doesn't list them; each class is just

class Foo : IJavaObject {}

instead of

class foo : ActualParent, IWhateverElse {}


All that is possible, of course, and would probably be pretty useful. But I didn't do it for the same reason everything is listed `final` right now - doing so would mean the vtable needs to be populated... which means the linker is going to go looking for those implementations. 4000 classes of implementations (and ungodly build time) forced on you when you probably only want a handful.

so.... well, this is my solution until it is dead or I find something better.

I do think interfaces are important long term, and since JNI actually dynamically binds by name there's a few options available to me to make it work, even with the lazy linking.

But for now if you look in the source, there's this stuff and a bunch of reinterpret cast FIXME comments in places where something needs to change for full support. just even without all that this is still pretty useful!