DMD or LDC on mobile

[Manu]

On Tue, Aug 20, 2019 at 12:30 PM kinke via Digitalmars-d
<digitalmars-d at 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. ;)