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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019
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 2019