Jump to page: 1 2 3
Thread overview
Add targets for release binaries? (1.3+)
Apr 22, 2017
Johan Engelen
Apr 22, 2017
David Nadlinger
Apr 22, 2017
Johan Engelen
Apr 28, 2017
Adrian Matoga
Apr 30, 2017
David Nadlinger
May 05, 2017
Adrian Matoga
May 05, 2017
David Nadlinger
May 05, 2017
Johan Engelen
May 05, 2017
Adrian Matoga
May 05, 2017
kinke
May 05, 2017
David Nadlinger
May 05, 2017
kinke
May 05, 2017
Adrian Matoga
May 05, 2017
kinke
May 05, 2017
Adrian Matoga
May 05, 2017
kinke
May 05, 2017
Adrian Matoga
May 14, 2017
Nicholas Wilson
Apr 22, 2017
kinke
Apr 22, 2017
Johan Engelen
Apr 22, 2017
kinke
Apr 23, 2017
Nicholas Wilson
April 22, 2017
Would it make sense to release 1.3 with more targets enabled than the host?
X86, ARM, AArch64 ?

- Johan
April 22, 2017
On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
> Would it make sense to release 1.3 with more targets enabled than the host?
> X86, ARM, AArch64 ?

I don't really think it makes sense for end users, as we would need to ship the respective standard libraries and a way to select between cross-compilation targets as well.

That being said, purely from a "marketing" perspective it might be nice to increase visibility for ARM support in LDC. (Users might read the -help output or just try to specify a target triple.)

The primary motivation behind shipping host-only releases was binary size - have you checked recently how the two build compare?

 -- David
April 22, 2017
On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
> Would it make sense to release 1.3 with more targets enabled than the host?
> X86, ARM, AArch64 ?
>
> - Johan

FWIW, the MSVC packages already feature a bunch of other targets incl. ARM and PowerPC [https://github.com/ldc-developers/ldc-scripts/blob/master/ldc2-msvc/RELEASE.proj#L67].
April 22, 2017
On Saturday, 22 April 2017 at 11:55:39 UTC, David Nadlinger wrote:
> On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
>> Would it make sense to release 1.3 with more targets enabled than the host?
>> X86, ARM, AArch64 ?
>
> I don't really think it makes sense for end users, as we would need to ship the respective standard libraries and a way to select between cross-compilation targets as well.

The extra standard libraries could be separate downloads (hosted by whoever), but there is also `-betterC`.
We could include a script that builds Phobos for a certain triple (I was already thinking about including such a script for building Phobos with LTO), but for druntime we don't include all the source...

> The primary motivation behind shipping host-only releases was binary size - have you checked recently how the two build compare?

Just tested: adding ARM and AArch64 to X86 on Mac adds 5 MB (LTO build).
April 22, 2017
On Saturday, 22 April 2017 at 12:51:23 UTC, kinke wrote:
> On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
>> Would it make sense to release 1.3 with more targets enabled than the host?
>> X86, ARM, AArch64 ?
>>
>> - Johan
>
> FWIW, the MSVC packages already feature a bunch of other targets incl. ARM and PowerPC

Ah, so let's use the same list for the ldc-scripts script?
April 22, 2017
On Saturday, 22 April 2017 at 14:53:46 UTC, Johan Engelen wrote:
> On Saturday, 22 April 2017 at 12:51:23 UTC, kinke wrote:
>> On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
>>> Would it make sense to release 1.3 with more targets enabled than the host?
>>> X86, ARM, AArch64 ?
>>>
>>> - Johan
>>
>> FWIW, the MSVC packages already feature a bunch of other targets incl. ARM and PowerPC
>
> Ah, so let's use the same list for the ldc-scripts script?

I don't have a strong opinion on this (and I didn't create that list), but a couple of MBytes (uncompressed) seem totally worth it to me (at least for x86 hosts), even if mainly for advertising the cross-compilation capabilities and target variety via `ldc2 --version`. With 1.3 able to generate entire static libs for all supported targets, it'd make some more sense I think.
April 23, 2017
On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
> Would it make sense to release 1.3 with more targets enabled than the host?
> X86, ARM, AArch64 ?
>
> - Johan

Not for 1.3, but once the compiler dcompute stuff is finished it'd be great to have NVPTX (and SPIRV once I get it into LLVM and we release with a version that has it). The increased visibility would be very god to have.
April 28, 2017
On Saturday, 22 April 2017 at 11:55:39 UTC, David Nadlinger wrote:
> On Saturday, 22 April 2017 at 10:21:05 UTC, Johan Engelen wrote:
>> Would it make sense to release 1.3 with more targets enabled than the host?
>> X86, ARM, AArch64 ?
>
> I don't really think it makes sense for end users, as we would need to ship the respective standard libraries and a way to select between cross-compilation targets as well.

Moreover, "ARM" alone doesn't mean anything in this context. The sheer number of platforms using different ABIs, architecture versions, library versions and configurations makes it virtually impossible to even build druntime and Phobos in a way that they could later be at least linked correctly for all ARM-based platforms.

That being said, having binary packages that work out-of-the-box for a few popular targets, such as Raspbian, Android and OS X, wouldn't be a bad thing.
April 30, 2017
On 28 Apr 2017, at 9:23, Adrian Matoga via digitalmars-d-ldc wrote:
> Moreover, "ARM" alone doesn't mean anything in this context. The sheer number of platforms using different ABIs, architecture versions, library versions and configurations makes it virtually impossible to even build druntime and Phobos in a way that they could later be at least linked correctly for all ARM-based platforms.
>
> That being said, having binary packages that work out-of-the-box for a few popular targets, such as Raspbian, Android and OS X, wouldn't be a bad thing.

True. But as you mention, there are a couple of popular targets. For example, Debian/Ubuntu/Fedora/Arch/… all have an armhf distribution which targets ARMv7 without NEON. A binary package for that would already cover a huge portion of people just looking to try out LDC on their ARM dev board. (RP1 is of course its own thing, unfortunately.)

 — David
May 05, 2017
On Sunday, 30 April 2017 at 15:44:50 UTC, David Nadlinger wrote:
> On 28 Apr 2017, at 9:23, Adrian Matoga via digitalmars-d-ldc wrote:
>> Moreover, "ARM" alone doesn't mean anything in this context. The sheer number of platforms using different ABIs, architecture versions, library versions and configurations makes it virtually impossible to even build druntime and Phobos in a way that they could later be at least linked correctly for all ARM-based platforms.
>>
>> That being said, having binary packages that work out-of-the-box for a few popular targets, such as Raspbian, Android and OS X, wouldn't be a bad thing.
>
> True. But as you mention, there are a couple of popular targets. For example, Debian/Ubuntu/Fedora/Arch/… all have an armhf distribution which targets ARMv7 without NEON. A binary package for that would already cover a huge portion of people just looking to try out LDC on their ARM dev board. (RP1 is of course its own thing, unfortunately.)

Yeah, GDC has a binary release for cross-compiling to armhf, which works well for RPi (including v1) out of the box. It's really a huge time saver.

What I miss the most in LDC is the ability to build and use druntime/Phobos for different targets (including subtargets, e.g. different ARM architecture versions and ABIs) with the same compiler. I'd like to add it myself, but I don't really know where to start. Perhaps it's an idea to be discussed at this DConf's hackathon.
« First   ‹ Prev
1 2 3