www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD or LDC on mobile

reply Ethan <gooberman gmail.com> writes:
tl;dr - I'm after a status report, and this thing pops up on 
forums often enough that I want the information in one place.

Aight guys. So here's the deal. That program I showed off at 
DConf this year? I have a potential customer interested in 
beginning usage in August.

They develop for mobile platforms. This means I'll need mobile 
support.

D is uniquely situated for my needs on all platforms going 
forward (you know, once the garbage collector is something we can 
talk about in terms of pride and not like the misbehaving child 
that won't grow up). That, of course, means it needs to compile 
and run on all platforms. Which realistically means code 
generation for two architectures these days (x64, ARM) and 
runtime support for non-desktop platforms (iOS, Android, consoles 
- although that last one is something almost everyone here can't 
work on).

Now, being a middleware, I'll be expecting the engine integration 
to supply routines like file operations and memory operations. 
Standard stuff.

I can probably totally avoid Phobos and avoid linking that 
behemoth in the runtime.

So that leaves code gen and druntime being usable.

I'll need to know before I work on my runtime library if these 
are usable. Otherwise, I'm going to have to write the runtime in 
C++ and write more code generation definitions to export the work 
I've already done to C++.

Do these two things work currently?
Jul 25
parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Thursday, 25 July 2019 at 13:21:01 UTC, Ethan wrote:
 tl;dr - I'm after a status report, and this thing pops up on 
 forums often enough that I want the information in one place.

 Aight guys. So here's the deal. That program I showed off at 
 DConf this year? I have a potential customer interested in 
 beginning usage in August.

 They develop for mobile platforms. This means I'll need mobile 
 support.

 D is uniquely situated for my needs on all platforms going 
 forward (you know, once the garbage collector is something we 
 can talk about in terms of pride and not like the misbehaving 
 child that won't grow up). That, of course, means it needs to 
 compile and run on all platforms. Which realistically means 
 code generation for two architectures these days (x64, ARM) and 
 runtime support for non-desktop platforms (iOS, Android, 
 consoles - although that last one is something almost everyone 
 here can't work on).

 Now, being a middleware, I'll be expecting the engine 
 integration to supply routines like file operations and memory 
 operations. Standard stuff.

 I can probably totally avoid Phobos and avoid linking that 
 behemoth in the runtime.

 So that leaves code gen and druntime being usable.

 I'll need to know before I work on my runtime library if these 
 are usable. Otherwise, I'm going to have to write the runtime 
 in C++ and write more code generation definitions to export the 
 work I've already done to C++.

 Do these two things work currently?
LDC for android is working with most of druntime & phobos. you can install ldc 1.13.0 from termux, I am also be able to build 1.16 with some phobos & druntime small bugs. IOS https://github.com/smolt/ldc-iphone-dev/releases only have 0.17.0-alpha1 (2.068.2 FE) LLVM 3.6.2. If LDC core team can only cherry-pick target/march for IOS, then I think people will be easy to try the ABI them self.
Jul 25
parent reply Ethan <gooberman gmail.com> writes:
On Thursday, 25 July 2019 at 13:49:39 UTC, Newbie2019 wrote:
 IOS https://github.com/smolt/ldc-iphone-dev/releases only have 
 0.17.0-alpha1 (2.068.2 FE) LLVM 3.6.2.
Sweet zombie Jesus that's dire. Mobile game developers make the lion's share of their income from iOS. I can deal with development builds of a compiler. But that needs to be in a significantly better state for people to even consider D on mobile a serious thing. And, you know, in general, there's more mobile devices on the web than desktop devices.
Jul 25
next sibling parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:
 Sweet zombie Jesus that's dire.

 Mobile game developers make the lion's share of their income 
 from iOS.

 I can deal with development builds of a compiler. But that 
 needs to be in a significantly better state for people to even 
 consider D on mobile a serious thing.

 And, you know, in general, there's more mobile devices on the 
 web than desktop devices.
I believe mobile hardware is get more and more powerful and necessary for everybody. The next year Arm A77 and Apple A13 will fast then laptop. This is a huge market and the largest number of user groups ever. D core team should take mobile serious and provide basic support. The current status is limit support from LDC team, and about zero man hours investment into IOS for so many years(last release since 2015). Android in a better status, but we loss the key developer last year. Consider there is consider there is about five billion people use mobile every more than 2 hours every day, but D language developer investment zero man hours into IOS for so many years. I can't image how many opportunity is passed for D.
Jul 25
next sibling parent reply a11e99z <black80 bk.ru> writes:
On Thursday, 25 July 2019 at 17:07:03 UTC, Newbie2019 wrote:
 On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:

 This is a huge market and the largest number of user groups 
 ever.
   D core team should take mobile serious and provide basic 
 support.

 Consider there is consider there is about five billion people 
 use mobile every more than 2 hours every day, but  D language 
 developer  investment zero man hours into IOS for so many years.

 I can't image how many opportunity is passed for D.
imo mobile devs is splitted by Swift and Java/Kotlin as natives and Unity for games. it will be impossible to change something in this area. even Go/Rust and others are relaxed about it.
Jul 25
next sibling parent a11e99z <black80 bk.ru> writes:
On Thursday, 25 July 2019 at 17:11:56 UTC, a11e99z wrote:
 On Thursday, 25 July 2019 at 17:07:03 UTC, Newbie2019 wrote:
 On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:
imo mobile devs is splitted by Swift and Java/Kotlin as natives and Unity for games. it will be impossible to change something in this area. even Go/Rust and others are relaxed about it.
more interesting is WASM cuz PWA & SPA exists that can be build with WASM that will work on mobiles too
Jul 25
prev sibling parent Ethan <gooberman gmail.com> writes:
On Thursday, 25 July 2019 at 17:11:56 UTC, a11e99z wrote:
 imo mobile devs is splitted by Swift and Java/Kotlin as natives
And that's great. But I'm not writing high-performance easy-to-maintain multi-platform code in those languages. My software will plug in to Unity and Unreal Engine. If D can't target iOS (moreso than Android) then I straight up can't use D for the runtime. And if I can't target iOS, then there's a very good chance I'm not going to use D for mobile gaming ever. Which in this day in age is one step removed from just straight up not using it in gaming.
Jul 25
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 25 July 2019 at 17:07:03 UTC, Newbie2019 wrote:
   D core team should take mobile serious and provide basic 
 support.
I'm not sure what this statement means? Should they put a team of their paid developers on it? That's simply not how this project works...
 I can't image how many opportunity is passed for D.
If there's business interest because that's a lucrative market, those who profit from it need to fund the development. It's hard to see how it's an "opportunity" if you're donating your free time so companies can make money.
Jul 25
parent Newbie2019 <newbie2019 gmail.com> writes:
On Thursday, 25 July 2019 at 18:52:16 UTC, bachmeier wrote:

 If there's business interest because that's a lucrative market, 
 those who profit from it need to fund the development. It's 
 hard to see how it's an "opportunity" if you're donating your 
 free time so companies can make money.
What about the people they are just want to enjoy the mobile develop with D ? Why every one has to care about business interest ? Look at the Github trending, most people contribute without business interest. And D trending is empty almost all the time.
Jul 25
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 25 July 2019 at 17:07:03 UTC, Newbie2019 wrote:
 On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:


 I believe mobile hardware is get more and more powerful and 
 necessary for everybody.  The next year Arm A77 and Apple A13  
 will fast then laptop.

 This is a huge market and the largest number of user groups 
 ever.
   D core team should take mobile serious and provide basic 
 support.

 The current status is limit support from LDC team,  and  about 
 zero man hours investment into IOS for so many years(last 
 release since 2015).

 Android in a better status, but we loss the key developer last 
 year.


 Consider there is consider there is about five billion people 
 use mobile every more than 2 hours every day, but  D language 
 developer  investment zero man hours into IOS for so many years.

 I can't image how many opportunity is passed for D.
The lack of support for mobile (I first inquired about mobile support in 2015) was the ultimate deal breaker for me. It's not rocket science, one could see that mobile was getting more and more important and people would ask if the software also worked on mobile. The answer would be embarrassing, as in "No, but D has CTFE and mixins." So I _had_ to move on. I stopped all development in D and started to rewrite the code in Kotlin (which btw was / is a real pleasure). I still can't get my head around the way mobile has been treated by the leadership and parts of the community. It's so darn obvious that mobile is important (e.g. gaming as the OP said) and yet it is treated like an unimportant detail only some people care about. Apparently D wants to compete with Go/Rust and emulate their features. But the thing is that mobile development attracts a huge crowd and D could clearly benefit from that, but nobody seems to care. I wonder why that is. I really do wonder. As the OP pointed out gaming + mobile is a huge market, but devs are forced to use C++ instead. What a waste. And as for the "Then DIY" brigade, no, mobile support should be clean and out of the box, not a hack, because it's going to be a product. Therefore it should be dealt with by the core team in order to have seamless integration.
Jul 27
parent reply Kagamin <spam here.lot> writes:
On Saturday, 27 July 2019 at 08:52:19 UTC, Chris wrote:
 The lack of support for mobile (I first inquired about mobile 
 support in 2015) was the ultimate deal breaker for me.
I think the deal breaker here is that the whole thing must happen on Macintosh and XCode.
Jul 27
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 27/07/2019 9:31 PM, Kagamin wrote:
 On Saturday, 27 July 2019 at 08:52:19 UTC, Chris wrote:
 The lack of support for mobile (I first inquired about mobile support 
 in 2015) was the ultimate deal breaker for me.
I think the deal breaker here is that the whole thing must happen on Macintosh and XCode.
You can rent VM's so that's not an issue. At some point you will need to get a license from Apple if you are selling software so there is going to be cost involved no matter what we do.
Jul 27
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:
 On Thursday, 25 July 2019 at 13:49:39 UTC, Newbie2019 wrote:
 IOS https://github.com/smolt/ldc-iphone-dev/releases only have 
 0.17.0-alpha1 (2.068.2 FE) LLVM 3.6.2.
Sweet zombie Jesus that's dire. Mobile game developers make the lion's share of their income from iOS. I can deal with development builds of a compiler. But that needs to be in a significantly better state for people to even consider D on mobile a serious thing. And, you know, in general, there's more mobile devices on the web than desktop devices.
As someone also interested in iOS in LDC, maybe we can pool money to make it happen? There are other companies interested in iOS target in LDC.
Jul 26
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 26 July 2019 at 12:22:47 UTC, Guillaume Piolat wrote:
 On Thursday, 25 July 2019 at 14:08:20 UTC, Ethan wrote:
 On Thursday, 25 July 2019 at 13:49:39 UTC, Newbie2019 wrote:
 IOS https://github.com/smolt/ldc-iphone-dev/releases only 
 have 0.17.0-alpha1 (2.068.2 FE) LLVM 3.6.2.
Sweet zombie Jesus that's dire. Mobile game developers make the lion's share of their income from iOS. I can deal with development builds of a compiler. But that needs to be in a significantly better state for people to even consider D on mobile a serious thing. And, you know, in general, there's more mobile devices on the web than desktop devices.
As someone also interested in iOS in LDC, maybe we can pool money to make it happen? There are other companies interested in iOS target in LDC.
For example, other interested parties here: https://forum.dlang.org/post/chggdrupcmfajnpevkai forum.dlang.org
Jul 26
prev sibling parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Friday, 26 July 2019 at 12:22:47 UTC, Guillaume Piolat wrote:
 As someone also interested in iOS in LDC, maybe we can pool 
 money to make it happen?

 There are other companies interested in iOS target in LDC.
I willing to donate 100$ for anyone made LDC latest version working for IOS with betterC (include tls support, but not mandatory for druntime support).
Jul 26
next sibling parent reply Ethan <gooberman gmail.com> writes:
On Saturday, 27 July 2019 at 05:15:57 UTC, Newbie2019 wrote:
 I willing to donate 100$ for anyone made LDC latest version 
 working for IOS with betterC (include tls support, but not 
 mandatory for druntime support).
When my company gets off the ground, I fully intend on investing in D financially. But right now I'm cash strapped. It's a bootstrap paradox for me. Chickens and eggs and all those other things.
Jul 27
parent Ethan <gooberman gmail.com> writes:
On Saturday, 27 July 2019 at 12:04:38 UTC, Ethan wrote:
 When my company gets off the ground, I fully intend on 
 investing in D financially.

 But right now I'm cash strapped.

 It's a bootstrap paradox for me. Chickens and eggs and all 
 those other things.
And now we've got a bug bounty system. Which means it's time to collect all the issues together that stop iOS/Android support being a first-class supported OS in D and throw some money at them directly.
Aug 17
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jul 26, 2019 at 10:20 PM Newbie2019 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 26 July 2019 at 12:22:47 UTC, Guillaume Piolat wrote:
 As someone also interested in iOS in LDC, maybe we can pool
 money to make it happen?

 There are other companies interested in iOS target in LDC.
I willing to donate 100$ for anyone made LDC latest version working for IOS with betterC (include tls support, but not mandatory for druntime support).
If there's a path to finance 1st class D support on mobile, I'll contribute substantially. I would he happy to do a classic thing like, for every donation to that effort, I will contribute an additional 50%... I don't know anybody who could work on this as a serious project who is motivated by money though... we probably need $3-5k at least to make someone interested. LDC needs to have official iOS/Android build distributions with unit tests passing... how do we get there?
Aug 19
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 20 August 2019 at 00:38:36 UTC, Manu wrote:
 I don't know anybody who could work on this as a serious 
 project who
 is motivated by money though... we probably need $3-5k at least 
 to
I'm between jobs right now, 3-5k might actually get my attention. But every time I look into mobile for myself, I just can't bring myself to care. To the extent that I want custom functionality on one of these devices, I just go back to web stuff. So so so so so much lower barrier to entry and then it works in other places too. But meh I've done stuff for money I personally don't use before and could again. Just for like $100 bounties that doesn't even cover enough time to seriously get started on something like this.
Aug 19
parent reply Manu <turkeyman gmail.com> writes:
On Mon, Aug 19, 2019 at 8:20 PM Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 20 August 2019 at 00:38:36 UTC, Manu wrote:
 I don't know anybody who could work on this as a serious
 project who
 is motivated by money though... we probably need $3-5k at least
 to
I'm between jobs right now, 3-5k might actually get my attention. But every time I look into mobile for myself, I just can't bring myself to care. To the extent that I want custom functionality on one of these devices, I just go back to web stuff. So so so so so much lower barrier to entry and then it works in other places too. But meh I've done stuff for money I personally don't use before and could again. Just for like $100 bounties that doesn't even cover enough time to seriously get started on something like this.
Right, it's not a 3-digit problem. It's probably a 5-digit problem, but in the D community, a 4-digit sum requires quite a bit of rallying. I think if someone (like yourself) who had the confidence of the community and a record for delivering were to take the challenge, we could probably arrange to fund it. Most computers on earth run Android or iOS, and it's embarrassing for us that we don't have a toolchain that works out of the box, and passes CI. We even have extern(Objective-C) readily available! It's such a missed opportunity!
Aug 19
next sibling parent reply Ethan <gooberman gmail.com> writes:
On Tuesday, 20 August 2019 at 06:58:33 UTC, Manu wrote:
 Right, it's not a 3-digit problem. It's probably a 5-digit 
 problem,
 but in the D community, a 4-digit sum requires quite a bit of
 rallying.
 I think if someone (like yourself) who had the confidence of the
 community and a record for delivering were to take the 
 challenge, we
 could probably arrange to fund it.
 Most computers on earth run Android or iOS, and it's 
 embarrassing for
 us that we don't have a toolchain that works out of the box, and
 passes CI.
 We even have extern(Objective-C) readily available! It's such a 
 missed
 opportunity!
So, I got hope recently that I'll finally be paid for some work I did last year. Surprise, no response to my emails again. But assuming that *FINALLY* comes through. I was planning on a minimum of €500 for getting iOS/Android closer. I don't want to just post €500 to the bug bounty though with unclear requirements. Rather than saying "here's a big lump sum" my idea instead is to itemise exactly what's required to get LDC providing first-class support and attach a dollar sum to each item. This way, it's basically just reducing it to a milestone with tasks that require completion. And it also means more than one person can work on it. I guess it makes it harder to rally the troops to pool money for fund, unless someone sets up a GoFundMe or something and has complete transparency over where the funds are going. ----- And since it directly relates to my first post in this thread. The potential customer mentioned will become an actual customer within a couple of months. So this leaves me two options: 1) Gamble (literally, by throwing money at the problem) that iOS/Android support will appear very quickly so that their milestones aren't hampered by D's lacking ecosystem support 2) Write the runtime component in C++ This middleware will stealth introduce D in to the wider gaming world. But only if I can actually link and execute on the platforms nearly 60% of devices in the world currently use.
Aug 20
parent a11e99z <black80 bk.ru> writes:
On Tuesday, 20 August 2019 at 09:32:05 UTC, Ethan wrote:
 On Tuesday, 20 August 2019 at 06:58:33 UTC, Manu wrote:

 And since it directly relates to my first post in this thread. 
 The potential customer mentioned will become an actual customer 
 within a couple of months. So this leaves me two options:

 1) Gamble (literally, by throwing money at the problem) that 
 iOS/Android support will appear very quickly so that their 
 milestones aren't hampered by D's lacking ecosystem support
 2) Write the runtime component in C++
for Android: u should make interop with Android so pay attention to alternative NDK https://www.crystax.net/android/ndk 4 years ago it was better choice than Google NDK
Aug 20
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-08-20 08:58, Manu wrote:

 We even have extern(Objective-C) readily available! It's such a missed
 opportunity!
Unfortunately it's only very limited support for "extern(Objective-C)" which is implemented in LDC. The later additions that exist in DMD have not been implemented in LDC. -- /Jacob Carlborg
Aug 20
next sibling parent reply JN <666total wp.pl> writes:
On Tuesday, 20 August 2019 at 09:32:38 UTC, Jacob Carlborg wrote:
 On 2019-08-20 08:58, Manu wrote:

 We even have extern(Objective-C) readily available! It's such 
 a missed
 opportunity!
Unfortunately it's only very limited support for "extern(Objective-C)" which is implemented in LDC. The later additions that exist in DMD have not been implemented in LDC.
Isn't that a good example of why "having three compilers" is not necessarily good for D? It's often praised as a good thing, but then we come across such things, when compiler X1 is good for Y, but compiler X2 isn't good at it, and things done for one compiler need to be ported to the other compiler.
Aug 20
parent Ethan <gooberman gmail.com> writes:
On Tuesday, 20 August 2019 at 10:34:30 UTC, JN wrote:
 Isn't that a good example of why "having three compilers" is 
 not necessarily good for D? It's often praised as a good thing, 
 but then we come across such things, when compiler X1 is good 
 for Y, but compiler X2 isn't good at it, and things done for 
 one compiler need to be ported to the other compiler.
There's no way I'd have gotten Quantum Break out the door if LDC was the only option for example. That's the reality of the world. Platform holders expect you to use certain compiler tool chains. I don't see how this example is any different. Given that all three active compilers (DMD, LDC, GDC) are based off the same frontend, at the very least I'd expect the frontends to match for the versions they're based off. Backends? Nah. You're on your own there.
Aug 20
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, Aug 20, 2019 at 2:36 AM Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 2019-08-20 08:58, Manu wrote:

 We even have extern(Objective-C) readily available! It's such a missed
 opportunity!
Unfortunately it's only very limited support for "extern(Objective-C)" which is implemented in LDC. The later additions that exist in DMD have not been implemented in LDC.
Is that a thing you're interested in? It would be valuable work. How's swift compatibility? Does Swift lean on the same ABI for backwards compatibility, or is it a completely new thing?
Aug 20
parent Jacob Carlborg <doob me.com> writes:
On 2019-08-20 20:14, Manu wrote:

 Is that a thing you're interested in? It would be valuable work.
Yes, I would be interested in working on that. But it's not a priority for me right now. So it would not happen anytime soon if I only work on this on my spare time.
 How's swift compatibility? Does Swift lean on the same ABI for
 backwards compatibility, or is it a completely new thing?
It's the same as with D. It uses its own ABI and supports the ` objc` attribute, which corresponds to `extern(Objective-C)` in D. -- /Jacob Carlborg
Aug 21
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 20 August 2019 at 00:38:36 UTC, Manu wrote:
 If there's a path to finance 1st class D support on mobile
I think you can use the bug bounty system Mike just announced.
Aug 20
parent Manu <turkeyman gmail.com> writes:
On Tue, Aug 20, 2019 at 12:05 AM Dukc via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 20 August 2019 at 00:38:36 UTC, Manu wrote:
 If there's a path to finance 1st class D support on mobile
I think you can use the bug bounty system Mike just announced.
It doesn't have the feature I described, but yeah we could use that system...
Aug 20
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-08-20 02:38, Manu wrote:

 If there's a path to finance 1st class D support on mobile, I'll
 contribute substantially.
 I would he happy to do a classic thing like, for every donation to
 that effort, I will contribute an additional 50%...
 
 I don't know anybody who could work on this as a serious project who
 is motivated by money though... we probably need $3-5k at least to
 make someone interested.
 LDC needs to have official iOS/Android build distributions with unit
 tests passing... how do we get there?
I do have some interest in this, but not enough to do on my spare time. Might be possible if I could get enough money and take some time off from work. -- /Jacob Carlborg
Aug 20
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, Aug 20, 2019 at 2:40 AM Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 2019-08-20 02:38, Manu wrote:

 If there's a path to finance 1st class D support on mobile, I'll
 contribute substantially.
 I would he happy to do a classic thing like, for every donation to
 that effort, I will contribute an additional 50%...

 I don't know anybody who could work on this as a serious project who
 is motivated by money though... we probably need $3-5k at least to
 make someone interested.
 LDC needs to have official iOS/Android build distributions with unit
 tests passing... how do we get there?
I do have some interest in this, but not enough to do on my spare time. Might be possible if I could get enough money and take some time off from work.
What kind of budget is motivating? I think the community needs nothing less than: Android/iOS have builds alongside each LDC release, passing CI, and a getting-started guide showing how to get to work on those platforms. It can't be a question what shape those toolchains are in. They need to be reliably available. I don't know the scope of this task, who knows where each toolchain is at? Can anyone itemise the work here?
Aug 20
next sibling parent reply kinke <noone nowhere.com> writes:
On Tuesday, 20 August 2019 at 18:17:42 UTC, Manu wrote:
 I don't know the scope of this task
I doubt anyone does. I'd definitely start with separating Android and iOS; Android probably just needs some polishing, while there's surely more to do for iOS (watchOS? tvOS? bananaOS?). Then clearly define the desired platforms, not just the OS - e.g., ARMv6 too, or just ARMv7 and AArch64? Is Android/x86_64 relevant too? ? You might wonder if there's much difference to regular Linux, except for Bionic instead of glibc/musl/uclibc - there is, e.g., the used `real`/C `long double` is apparently a software quad-precision format, apparently for AArch64 compatibility... If proper ABI compatibility with C(++) is desired (one can get quite far with a hacky rudimentary implementation), then that should be specified as well. While working out the ABI details and getting LLVM to do what you want can be tedious, ABI handling should be much simpler for gdc according to Iain. Probably the most important aspect/prerequisite is setting up CI, incl. automated release builds. This includes setting up CI for our LLVM fork as well (e.g., required on Android due to custom TLS emulation...) - no real CI, just building and packaging LLVM, which can take quite a while; luckily, it should be fairly simple to cross-compile LLVM on x86. If there's no free CI service providing what's needed, then someone interested would have to provide some infrastructure or pay the bills. Note that emulators running on x86 hosts *might* suffice; e.g., building the druntime/Phobos unittest runners (big chunk of overall time) can be done natively on the host by cross-compiling - today. Running the DMD testsuite takes rather long as well, so if doing that in an emulator, one might easily run into CI time-outs (but Azure offers 6h...). Once settled for a CI service, setting up CI and polishing isn't rocket-science, just tedious; no programming skills required at all. ;)
Aug 20
next sibling parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Tuesday, 20 August 2019 at 19:26:47 UTC, kinke wrote:
 I doubt anyone does.
The Android LDC is basic work without need a lot work, the most of job need to be done is for IOS. IMHO, The job could be split into multi tasks: 1) add --arch|--march basic support for the ldc main branch, so any one Interested no need do the job again. this part job require some LDC Professional knowledge so It need some guide from LDC team. 2) add basic ABI support with unimplement exception for LDC branch. or a CMAKE options to allow people twist themself. 3) implement the ABI and pass basic betterC tests, In this stage ldc already able to work for some project no need druntime. I said before for this stage I willing donation 100$ for this. 4) fix the druntime to support TLS and GC. 5) setup the CI Most successful projects benefit from teamwork, we should embrace more perspective of project manager.
Aug 20
parent Chris <wendlec tcd.ie> writes:
On Tuesday, 20 August 2019 at 22:52:54 UTC, Newbie2019 wrote:
 On Tuesday, 20 August 2019 at 19:26:47 UTC, kinke wrote:
 I doubt anyone does.
The Android LDC is basic work without need a lot work, the most of job need to be done is for IOS. IMHO, The job could be split into multi tasks: 1) add --arch|--march basic support for the ldc main branch, so any one Interested no need do the job again. this part job require some LDC Professional knowledge so It need some guide from LDC team. 2) add basic ABI support with unimplement exception for LDC branch. or a CMAKE options to allow people twist themself. 3) implement the ABI and pass basic betterC tests, In this stage ldc already able to work for some project no need druntime. I said before for this stage I willing donation 100$ for this. 4) fix the druntime to support TLS and GC. 5) setup the CI Most successful projects benefit from teamwork, we should embrace more perspective of project manager.
Maybe have a look at Android Studio and their toolchain. For C/C++ they use CMake and the output is in a folder called ".externalNativeBuild/cmake/". It produces the following output (in my project): - arm64-v8a - armeabi-v7a - x86 - x86_64 Maybe it'd make sense to look at the respective toolchains first, Android Studio and Xcode. Also, have a look at Kotlin Multiplatform[1], especially the Android-iOS integration[2]. It compiles the code that apps have in common to native and it uses the LLVM toolchain. Afik, they modified it a bit, check it out on Github[3]. [1] https://kotlinlang.org/docs/reference/multiplatform.html [2] https://kotlinlang.org/docs/tutorials/native/mpp-ios-android.html [3] https://github.com/JetBrains/kotlin-native/
Aug 21
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, Aug 20, 2019 at 12:30 PM kinke via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 20 August 2019 at 18:17:42 UTC, Manu wrote:
 I don't know the scope of this task
I doubt anyone does. I'd definitely start with separating Android and iOS; Android probably just needs some polishing, while there's surely more to do for iOS (watchOS? tvOS? bananaOS?). Then clearly define the desired platforms, not just the OS - e.g., ARMv6 too, or just ARMv7 and AArch64? Is Android/x86_64 relevant too? ? You might wonder if there's much difference to regular Linux, except for Bionic instead of glibc/musl/uclibc - there is, e.g., the used `real`/C `long double` is apparently a software quad-precision format, apparently for AArch64 compatibility... If proper ABI compatibility with C(++) is desired (one can get quite far with a hacky rudimentary implementation), then that should be specified as well. While working out the ABI details and getting LLVM to do what you want can be tedious, ABI handling should be much simpler for gdc according to Iain. Probably the most important aspect/prerequisite is setting up CI, incl. automated release builds. This includes setting up CI for our LLVM fork as well (e.g., required on Android due to custom TLS emulation...) - no real CI, just building and packaging LLVM, which can take quite a while; luckily, it should be fairly simple to cross-compile LLVM on x86.
What does this stuff mean? LDC has traditionally integrated all the targets into the one build; including the exitoc GPU targets and friends. What is the additional build time you speak ontop of the existing build? Are Android/iOS just additional backend targets like the rest? I figured that ideally, support would be added to the standard build for those targets. That said; CI needs to run tests, which means some platform to execute them is necessary; if that's a cloud CI for mobiles, or an emulator on a normal CI VM, I think we have options that we can make something work.
 If there's no free CI service providing what's needed, then
 someone interested would have to provide some infrastructure or
 pay the bills. Note that emulators running on x86 hosts *might*
 suffice; e.g., building the druntime/Phobos unittest runners (big
 chunk of overall time) can be done natively on the host by
 cross-compiling - today. Running the DMD testsuite takes rather
 long as well, so if doing that in an emulator, one might easily
 run into CI time-outs (but Azure offers 6h...).
 Once settled for a CI service, setting up CI and polishing isn't
 rocket-science, just tedious; no programming skills required at
 all. ;)
Aug 20
parent reply kinke <kinke gmx.net> writes:
On Wednesday, 21 August 2019 at 02:10:17 UTC, Manu wrote:
 What does this stuff mean?
 LDC has traditionally integrated all the targets into the one 
 build;
 including the exitoc GPU targets and friends. What is the 
 additional
 build time you speak ontop of the existing build?
 Are Android/iOS just additional backend targets like the rest? I
 figured that ideally, support would be added to the standard 
 build for
 those targets.
Of course they are regular targets just like the others, and cross-compiling to Android etc. is possible today, with any x86 release package, and has been for years.
Aug 21
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Aug 21, 2019 at 2:35 AM kinke via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 21 August 2019 at 02:10:17 UTC, Manu wrote:
 What does this stuff mean?
 LDC has traditionally integrated all the targets into the one
 build;
 including the exitoc GPU targets and friends. What is the
 additional
 build time you speak ontop of the existing build?
 Are Android/iOS just additional backend targets like the rest? I
 figured that ideally, support would be added to the standard
 build for
 those targets.
Of course they are regular targets just like the others, and cross-compiling to Android etc. is possible today, with any x86 release package, and has been for years.
Okay, so what are you saying about the extra LLVM build time? Perhaps I misread; are you saying that LDC doesn't currently have CI of that nature at all? So, Android target works, but iOS not so much? What would you say is outstanding in Android front? Just passing CI? Is there druntime work to do? I suspect platform integration is scarce? Does Android x86 work? This is often used during debugging where I work. I've seen iOS toolchains appear from time to time, I guess the standard build can't emit iOS code though?
Aug 21
next sibling parent reply kinke <noone nowhere.com> writes:
On Wednesday, 21 August 2019 at 17:35:39 UTC, Manu wrote:
 Okay, so what are you saying about the extra LLVM build time?
I mentioned the LLVM CI/build because that would be required for a native Android/iOS LDC package (not sure how much demand there is). As we don't have any 32-bit ARM CI either (but an AArch64 one), this means that someone needs to build LLVM manually for the prebuilt armhf packages. [And building LLVM with 3 emulated ARMv7 cores on my i5-3550 quad-core takes about 12 hours, just to give you an idea wrt. emulator performance.]
 So, Android target works, but iOS not so much?
 What would you say is outstanding in Android front? Just 
 passing CI?
 Is there druntime work to do? I suspect platform integration is
 scarce?
I don't know because I've never tried to target Android or iOS (not interested at all myself, I mostly just use the browser on my phone). There should be plenty of information in older LDC GitHub PRs/issues, in the Wiki and possibly even this forum. - IIRC, most tests are passing on Android for 32-bit ARM and AArch64 (but don't expect proper C++ ABI compatibility). Generating shared libs (obviously) works, but multiple .so's cannot share a druntime.so (e.g., one GC for all shared D libs), contrary to regular Linux and macOS.
 Does Android x86 work?
I'm not sure whether Joakim tested it, but he did definitely work on adding druntime support for it, and LDC uses the 128-bit quad-precision `real` type.
 I've seen iOS toolchains appear from time to time, I guess the 
 standard build can't emit iOS code though?
No idea (code emission per se shouldn't be that big a deal and probably works today, it's more about druntime - exception handling, TLS, shared libs support etc.). Dan Olson ( smolt) worked on an iOS fork of LDC some time ago, but IIRC, he didn't upstream many of his patches to mainline LDC.
Aug 21
next sibling parent kinke <noone nowhere.com> writes:
On Wednesday, 21 August 2019 at 19:00:57 UTC, kinke wrote:
 I mentioned the LLVM CI/build because that would be required 
 for a native Android/iOS LDC package
Correction: it's also needed for running the DMD tests in the `runnable` subdir as well as similar LDC-specific tests, which require a native LDC build.
Aug 21
prev sibling parent reply Laeeth Isharc <laeeth kaleidic.io> writes:
losing your read post history.
10 hours agoRe: DMD or LDC on mobile
Gravatar	Posted by kinke
in reply to Manu	
Permalink
Reply
On Wednesday, 21 August 2019 at 17:35:39 UTC, Manu wrote:
 Okay, so what are you saying about the extra LLVM build time?
I mentioned the LLVM CI/build because that would be required for a native Android/iOS LDC package (not sure how much demand there is). As we don't have any 32-bit ARM CI either (but an AArch64 one), this means that someone needs to build LLVM manually for the prebuilt armhf packages. [And building LLVM with 3 emulated ARMv7 cores on my i5-3550 quad-core takes about 12 hours, just to give you an idea wrt. emulator performance.] --- I'll pay for Android CI and/or iOS if it's helpful. Please get in touch via John Colvin / Robert Schadek. We don't use Android at work but maybe some day we might. On the other hand even if iOS is done it's not so useful for writing full applications yet. But the journey of a thousand miles... It's worth it if we can to keep the termius LDC package build up to date. Also dlangui seems to have stagnated a bit on Android. I wonder if it's viable to write a little app that way. Otherwise I guess something like imgui. Laeeth
Aug 21
parent Newbie2019 <newbie2019 gmail.com> writes:
On Thursday, 22 August 2019 at 06:03:46 UTC, Laeeth Isharc wrote:
 losing your read post history.
 10 hours agoRe: DMD or LDC on mobile
 Gravatar	Posted by kinke
 in reply to Manu	
 Permalink
 Reply
 On Wednesday, 21 August 2019 at 17:35:39 UTC, Manu wrote:
 [...]
[...]
Is any expert can help me to start working on this : https://forum.dlang.org/thread/uqxjehxtplbgvxesfrez forum.dlang.org
Oct 19
prev sibling parent Exil <Exil gmall.com> writes:
On Wednesday, 21 August 2019 at 17:35:39 UTC, Manu wrote:
 So, Android target works, but iOS not so much?
 What would you say is outstanding in Android front? Just 
 passing CI?
 Is there druntime work to do? I suspect platform integration is
 scarce?
 Does Android x86 work? This is often used during debugging 
 where I work.
Work that was being done below, the person that was doing the majority of the work left the community iirc. https://github.com/ldc-developers/ldc/issues/2153 I've been using LDC for Android for a while. So for it works as expected, aside from a few things like va_args not being implemented (which can be fairly easily avoided). Don't really do any binding with C++ though, only C. I think x86 did work, I've never tried it though. Not sure about x86_64 either if that's relevant. I've used it pretty much exclusively with AArch64.
Aug 21
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-08-20 20:17, Manu wrote:

 What kind of budget is motivating?
 
 I think the community needs nothing less than:
 Android/iOS have builds alongside each LDC release, passing CI, and a
 getting-started guide showing how to get to work on those platforms.
 It can't be a question what shape those toolchains are in. They need
 to be reliably available.
What has not been mentioned so far, but I think is important as well, is to support the simulators. The iOS simulator is running x86(-64) as the architecture.
 I don't know the scope of this task, who knows where each toolchain is
 at? Can anyone itemise the work here?
I don't know. That will probably take some investigation. I only know about [1]. [1] mentions a custom LLVM with support for TLS. I think this is available in upstream LLVM now. [1] https://github.com/smolt/ldc-iphone-dev -- /Jacob Carlborg
Aug 21
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tue, 20 Aug 2019 at 20:18, Manu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tue, Aug 20, 2019 at 2:40 AM Jacob Carlborg via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 2019-08-20 02:38, Manu wrote:

 If there's a path to finance 1st class D support on mobile, I'll
 contribute substantially.
 I would he happy to do a classic thing like, for every donation to
 that effort, I will contribute an additional 50%...

 I don't know anybody who could work on this as a serious project who
 is motivated by money though... we probably need $3-5k at least to
 make someone interested.
 LDC needs to have official iOS/Android build distributions with unit
 tests passing... how do we get there?
I do have some interest in this, but not enough to do on my spare time. Might be possible if I could get enough money and take some time off from work.
What kind of budget is motivating? I think the community needs nothing less than: Android/iOS have builds alongside each LDC release, passing CI, and a getting-started guide showing how to get to work on those platforms. It can't be a question what shape those toolchains are in. They need to be reliably available. I don't know the scope of this task, who knows where each toolchain is at? Can anyone itemise the work here?
- Druntime. - Phobos. - Possibly a little help from the compiler with module support, (possibly emulated) tls, and adding ranges for GC scanning. I've been testing/developing gdc pretty much solely off my (Android) phone since the start of this year, and though I haven't committed anything to trunk yet, shared library work on OSX is pretty much feature complete - though don't ask me how I got gcc-9 working on OSX, I still have no idea myself, as the last supported version of gcc (4.2) can't build a working compiler from any of the recent releases, and druntime's core.cpuid uses opcodes that are unsupported by the default version of Xcode that came with the box. :-P As for the toolchain though, both Apple and Google have abandoned gcc in these respective toolchains, shame on them really. -- Iain
Aug 20
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 19, 2019 at 05:38:36PM -0700, Manu via Digitalmars-d wrote:
[...]
 LDC needs to have official iOS/Android build distributions with unit
 tests passing... how do we get there?
Right now, LDC does work for Android builds. I have two experimental Android projects that still compile. The instructions can be found on the wiki. It's not perfect, of course; somebody should work on putting things together in a nicer packaging that doesn't involve users downloading and compiling LDC manually. And also, since Joakim left over some ideological issues, there's no longer any active maintainer of the Android target for LDC, so we need someone to step up. T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Aug 20