www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - FYI: Master is now at D 2.074.1

reply kinke <noone nowhere.com> writes:
And I'm aiming for a 1.4 beta release pretty soon.
Jul 28
parent reply Joakim <dlang joakim.fea.st> writes:
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
Jul 28
parent reply kinke <noone nowhere.com> writes:
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
Jul 28
parent reply Joakim <dlang joakim.fea.st> writes:
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.
Jul 28
parent reply kinke <noone nowhere.com> writes:
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.
Jul 28
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
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é
Jul 29
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
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.
Jul 29
parent reply kinke <noone nowhere.com> writes:
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.
Jul 29
parent Joakim <dlang joakim.fea.st> writes:
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.digitalma s-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'.
Jul 30