Thread overview
FYI: Master is now at D 2.074.1
Jul 28
kinke
Jul 28
Joakim
Jul 28
kinke
Jul 28
Joakim
Jul 28
kinke
Jul 29
Joakim
Jul 30
kinke
Jul 30
Joakim
July 28
And I'm aiming for a 1.4 beta release pretty soon.
July 28
On Friday, 28 July 2017 at 15:56:59 UTC, kinke wrote:
> And I'm aiming for a 1.4 beta release pretty soon.

Nice, been waiting for this.  I'd like to get versions of these two Android patches in for the next beta, so the official ldc release becomes a full Android cross-compiler, which users can just run your new cross-compilation script with to generate a cross-compiled stdlib:

https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a
https://gist.github.com/joakim-noah/d74af3cf1355492557a9c56ef1bf2636
July 28
On Friday, 28 July 2017 at 17:18:17 UTC, Joakim wrote:
> Nice, been waiting for this.  I'd like to get versions of these two Android patches in for the next beta, so the official ldc release becomes a full Android cross-compiler, which users can just run your new cross-compilation script with to generate a cross-compiled stdlib:

Yep, I've been looking forward to having Android support fully baked in too. :)

> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a

Wrt. the LLVM patch: We'll most likely use LLVM 4.0.1 for 1.4 (finally on Windows too). If the patch is still required for 4.0.1, we'll probably need to integrate it in our ldc-scripts [1], so that we can update the Docker image once with that tailored LLVM. Integrating the patch for LDC on Windows is probably not worth the effort.

> https://gist.github.com/joakim-noah/d74af3cf1355492557a9c56ef1bf2636

The runtime CMake script patch looks quite straightforward. The CMake variables are best put into a dedicated `build-ldc-runtime-android.sh` or something like it, which also sets `TARGET_SYSTEM=Android;Linux;UNIX` so that Android can be detected this way for the few special cases [is removing core.stdc.tgmath really required?].

So there should be no need to compile an additional combined druntime+Phobos testrunner anymore; cross-compiling with the script will yield the 2 normal separate testrunners (when setting the env variable `MAKE_ARGS="all all-test-runners"`). Afaict you didn't change anything there except for adding `-d-debug`.

I don't know what libnative-activity*.so, the biggest part of the patch, is; is it required?

[1]: https://github.com/ldc-developers/ldc-scripts/blob/master/ldc2-packaging/1-build-llvm.sh
July 28
On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
> Wrt. the LLVM patch: We'll most likely use LLVM 4.0.1 for 1.4 (finally on Windows too). If the patch is still required for 4.0.1, we'll probably need to integrate it in our ldc-scripts [1], so that we can update the Docker image once with that tailored LLVM. Integrating the patch for LDC on Windows is probably not worth the effort.

Why not?  It's small and only affects ELF TLS.  It would be nice for the Windows release of ldc to also work as an Android cross-compiler, to be used with the Android NDK for Windows.

>> https://gist.github.com/joakim-noah/d74af3cf1355492557a9c56ef1bf2636
>
> The runtime CMake script patch looks quite straightforward. The CMake variables are best put into a dedicated `build-ldc-runtime-android.sh` or something like it, which also sets `TARGET_SYSTEM=Android;Linux;UNIX` so that Android can be detected this way for the few special cases [is removing core.stdc.tgmath really required?].

I was thinking they'd simply be told to add those flags to their command-line, but a standalone script would be even easier, sure. core.stdc.tgmath unfortunately doesn't compile right now, as I never bothered to figure out all the aliases for the missing Bionic math functions in core.stdc.math.

> So there should be no need to compile an additional combined druntime+Phobos testrunner anymore; cross-compiling with the script will yield the 2 normal separate testrunners (when setting the env variable `MAKE_ARGS="all all-test-runners"`). Afaict you didn't change anything there except for adding `-d-debug`.

Yes, I'm looking forward to removing that and just using the existing command-line test-runners, properly cross-compiled.

> I don't know what libnative-activity*.so, the biggest part of the patch, is; is it required?

No, I was planning on leaving that out and maybe trying to get it in later.  It takes a simple, fully native, OpenGLES 1.0 GUI Android app that I ported from the NDK examples and invokes the test runner from there, so you can build a test runner apk (apk is the file extension for full Android apps, what you see in the official app store):

https://github.com/joakim-noah/android/tree/master/samples/native-activity
https://gist.github.com/joakim-noah/8ba3cd4958266f357295

It is good to test because the apk environment is slightly different from the command-line test-runner environment, because a native apk is a shared library that's invoked by their Java runtime.  I'm not sure if we want to test that as part of ldc too, but it can wait for later, even if we did.
July 28
On Friday, 28 July 2017 at 21:16:18 UTC, Joakim wrote:
> On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
>> Integrating the patch for LDC on Windows is probably not worth the effort.
>
> Why not?  It's small and only affects ELF TLS.  It would be nice for the Windows release of ldc to also work as an Android cross-compiler, to be used with the Android NDK for Windows.

Alright, then the MSBuild script will need to be adapted too: https://github.com/ldc-developers/ldc-scripts/blob/master/ldc2-msvc/RELEASE.proj
GNU tools like patch can be assumed to be available.

> It is good to test because the apk environment is slightly different from the command-line test-runner environment, because a native apk is a shared library that's invoked by their Java runtime.  I'm not sure if we want to test that as part of ldc too, but it can wait for later, even if we did.

Thanks for explaining, let's wait then. Looking good.
July 29
On Friday, 28 July 2017 at 23:36:21 UTC, kinke wrote:
> On Friday, 28 July 2017 at 21:16:18 UTC, Joakim wrote:
>> On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
>>> Integrating the patch for LDC on Windows is probably not worth the effort.
>>
>> Why not?  It's small and only affects ELF TLS.  It would be nice for the Windows release of ldc to also work as an Android cross-compiler, to be used with the Android NDK for Windows.

By chance I was this week wondering wheter it is possible to cross compile android applications from Windows.
It seems 2017 is the year of D. Every week there are fantastic news.
Thank you all for your great work!

Kind regards
André


July 29
On Friday, 28 July 2017 at 23:36:21 UTC, kinke wrote:
> On Friday, 28 July 2017 at 21:16:18 UTC, Joakim wrote:
>> On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
>>> Integrating the patch for LDC on Windows is probably not worth the effort.
>>
>> Why not?  It's small and only affects ELF TLS.  It would be nice for the Windows release of ldc to also work as an Android cross-compiler, to be used with the Android NDK for Windows.
>
> Alright, then the MSBuild script will need to be adapted too: https://github.com/ldc-developers/ldc-scripts/blob/master/ldc2-msvc/RELEASE.proj
> GNU tools like patch can be assumed to be available.

I'll rework my llvm patch so that it's enabled by a flag, which would then be flipped by ldc when passed the Android triple, and submit PRs for ldc and the packaging ldc-scripts for linux.  It'd help if you then simply applied the llvm patch in the same way for that MSVC build, as I don't have a Windows machine to test on.

On Saturday, 29 July 2017 at 09:20:55 UTC, Andre Pany wrote:
> On Friday, 28 July 2017 at 23:36:21 UTC, kinke wrote:
>> On Friday, 28 July 2017 at 21:16:18 UTC, Joakim wrote:
>>> On Friday, 28 July 2017 at 18:21:39 UTC, kinke wrote:
>>>> Integrating the patch for LDC on Windows is probably not worth the effort.
>>>
>>> Why not?  It's small and only affects ELF TLS.  It would be nice for the Windows release of ldc to also work as an Android cross-compiler, to be used with the Android NDK for Windows.
>
> By chance I was this week wondering wheter it is possible to cross compile android applications from Windows.
> It seems 2017 is the year of D. Every week there are fantastic news.
> Thank you all for your great work!

Heh, thanks for your docker image and other work getting the ldc cross-compiler going on Windows.  We may need you to test out this cross-compiler for Windows.  If you're comfortable building llvm and ldc from source, you may want to try it with my llvm patch now and see if it builds on Windows and all the tests pass on Android, by following the linux instructions on the wiki but using the Windows equivalents.

Otherwise, we'll try it on Windows later with the beta.
July 30
On Saturday, 29 July 2017 at 14:55:31 UTC, Joakim wrote:
> I'll rework my llvm patch so that it's enabled by a flag, which would then be flipped by ldc when passed the Android triple, and submit PRs for ldc and the packaging ldc-scripts for linux.

Perfect.

>  It'd help if you then simply applied the llvm patch in the same way for that MSVC build, as I don't have a Windows machine to test on.

Sure, will do.
And then there's still the issue that the build-ldc-runtime.sh script is a bash script, making use of wget etc. I guess it'd need to be duplicated as Windows batch file.
July 30
On Sunday, 30 July 2017 at 02:18:53 UTC, kinke wrote:
> On Saturday, 29 July 2017 at 14:55:31 UTC, Joakim wrote:
>> I'll rework my llvm patch so that it's enabled by a flag, which would then be flipped by ldc when passed the Android triple, and submit PRs for ldc and the packaging ldc-scripts for linux.
>
> Perfect.
>
>>  It'd help if you then simply applied the llvm patch in the same way for that MSVC build, as I don't have a Windows machine to test on.
>
> Sure, will do.
> And then there's still the issue that the build-ldc-runtime.sh script is a bash script, making use of wget etc. I guess it'd need to be duplicated as Windows batch file.

Hmm, didn't think of the script.  You know, reading Danny Coy on how he uses D for scripting (http://forum.dlang.org/post/mailman.5472.1501370784.31550.digitalmars-d@puremagic.com), maybe it'd be better if you rewrote the bash script in D, then it could easily be used on Windows too?  After all, it ships with a D compiler, and now that we include rdmd, we could just tell them to run 'rdmd build-ldc-runtime.d'.