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?

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

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. ;)

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.

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. ;)

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/

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.

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?

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

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