December 18, 2019
On Tuesday, 17 December 2019 at 22:28:32 UTC, kinke wrote:
> Instead of wrappers around ldc2 and dub, I'd prefer a little generic tool

My implementation is pretty generic - look at the source. All it really does is

foreach(target; [x86, x86_64, armv7, aarch64])
   dub build -a target;

and the android-ldc wrapper simply forwards to ldc2 to compile while calling a separate linker.

Both programs combined are < 100 lines. (I almost just did a shell script but figured easier to just do it in D for cross platform compatibility).
December 18, 2019
On Wednesday, 18 December 2019 at 00:33:38 UTC, Adam D. Ruppe wrote:
> On Tuesday, 17 December 2019 at 22:28:32 UTC, kinke wrote:
>> Instead of wrappers around ldc2 and dub, I'd prefer a little generic tool
>
> My implementation is pretty generic

I'm talking about genericity wrt. *all* targets, not just the 4 Android ones.

> and the android-ldc wrapper simply forwards to ldc2 to compile while calling a separate linker.
>
> Both programs combined are < 100 lines.

The android-ldc wrapper is already ~160 lines, and AFAICT, it's a rather cumbersome alternative to simply setting up ldc2.conf appropriately.
December 18, 2019
On Tuesday, 17 December 2019 at 23:18:33 UTC, H. S. Teoh wrote:
> I struggled a bit to get Windows build working, for example, because I didn't know the exact pattern to put in ldc2.conf at first. I tried various combinations that didn't work until I accidentally landed upon "x86_64-.*-windows.msvc" (the Wiki page was confusing; it's either outdated or incomplete, as I was trying "i686-.*-windows.*" to no avail).

The Wiki page specifies `x86_64-.*-windows-msvc`, all good.

> This is awesome stuff.  My current Android still uses Joakim's old guide that involves manually specifying a lot of stuff like explicit linker options, library and SDK paths, etc., on the command line. True, I only had to do it once and thereafter just put it in the build script, but having a standard automated scheme to abstract away such details would make it a lot more pleasant to use.

Yeah, that Wiki page needs to be updated, and the outlined tool would have to be implemented. ;) - Luckily, it should be rather simple to implement and doesn't require knowledge about LDC's inner workings (=> I'd rather spend my time elsewhere, don't count on me/the LDC team).

And wrt. Android, we're still not running any CI tests whatsoever, the only thing that is checked is compilability (and linkability of the native LDC Android builds), so that's also something that needs to be added before we can claim to have Android support. Reworking the TLS initialization and enabling full support for shared druntime/Android, as mentioned by Joakim in the Wiki page, is also still on the table.
December 18, 2019
On Wednesday, 18 December 2019 at 12:29:17 UTC, kinke wrote:
> The android-ldc wrapper is already ~160 lines, and AFAICT, it's a rather cumbersome alternative to simply setting up ldc2.conf appropriately.

tbh I didn't even know there was a such thing as ldc2.conf.

This indeed might be better and can prolly be upstreamed too. Maybe I can just set --linker=whatever... I'll play with it, thanks for the tip!
December 18, 2019
On Wednesday, 18 December 2019 at 15:04:14 UTC, Adam D. Ruppe wrote:
> tbh I didn't even know there was a such thing as ldc2.conf.

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.
December 18, 2019
On Wednesday, 18 December 2019 at 15:53:14 UTC, kinke wrote:
> Heh, it looks like the Wiki page

Yeah, I found the wiki pages just generally didn't actually work when I tried them; prolly outdated.

But your example there is simpler than I thought it would be. I'm gonna try using this.... probably next week as I'm out of town this week and my laptop can't do android stuff... but still this is looking good.

meanwhile i am working on jni from the laptop and that is going swimmingly.
December 18, 2019
On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:
> Runtime initialization is now working, and you can create a Java VM

I now have this tested and working on Windows and Linux.

> - Method overloading;

This is fixed in the newest commit too.


```D
import arsd.jni;

final class Test : JavaClass!("wtf", Test) {
        @Import this();
	@Import void cool();
}

void main() {
	auto jvm = createJvm();

	auto h = new Test();
	h.cool();
}
```

```Java

package wtf;

public class Test {
        public native void test_();
        void test() { test_(); }

        void cool() {
                System.out.println("********* super cool *******");
        }
}
```


As you can see there, the D code uses the java class almost as if it was native D. Overloads work now too as well as many types in many places, but not all in all cases. Still a good chunk of work to do but already super cool.


I've gotta shift my attention to COM and .net for a little while now though...
December 19, 2019
On Wednesday, 18 December 2019 at 19:57:43 UTC, Adam D. Ruppe wrote:
> On Tuesday, 17 December 2019 at 18:29:32 UTC, H. S. Teoh wrote:
>> Runtime initialization is now working, and you can create a Java VM
>
> I now have this tested and working on Windows and Linux.
>
>> - Method overloading;
>
> This is fixed in the newest commit too.
>
>
> ```D
> import arsd.jni;
>
> final class Test : JavaClass!("wtf", Test) {
>         @Import this();
> 	@Import void cool();
> }
>
> void main() {
> 	auto jvm = createJvm();
>
> 	auto h = new Test();
> 	h.cool();
> }
> ```
>
> ```Java
>
> package wtf;
>
> public class Test {
>         public native void test_();
>         void test() { test_(); }
>
>         void cool() {
>                 System.out.println("********* super cool *******");
>         }
> }
> ```
>
>
> As you can see there, the D code uses the java class almost as if it was native D. Overloads work now too as well as many types in many places, but not all in all cases. Still a good chunk of work to do but already super cool.
>
>
> I've gotta shift my attention to COM and .net for a little while now though...


Thanks a lot for this fantastic work. I want to do s.th. similar
for Delphi (For developing windows, android and ios applications)
and your work gives me some good inspiration.

I wonder whether D could be enhanced in future to make the CRTP
idiom a little bit nicer:

  class JavaClass(string javaPackage, CRTP) : IJavaObject {}

  final class Hello : JavaClass!("", Hello) {}


It would be nice, if I could specify s.th. like that:

  class JavaClass(string javaPackage = "", CRTP = @child) : IJavaObject {}

then I could just say:

  final class Hello : JavaClass

Kind regards
André



December 19, 2019
On Thursday, 19 December 2019 at 11:48:21 UTC, Andre Pany wrote:
> I wonder whether D could be enhanced in future to make the CRTP
> idiom a little bit nicer:

It is also possible to do a mixin for most the same result.

But yeah if the language were to change there's some fun things. The two I have considered is something similar to what you wrote and also putting an automatic child mixin in the parent class/interface.

Just I work with what we have, not what might happen at some point in the future :)
December 31, 2019
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.