Thread overview | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 22, 2017 Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Would it make sense to release 1.3 with more targets enabled than the host? X86, ARM, AArch64 ? - Johan |
April 22, 2017 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adrian Matoga | 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 Re: Add targets for release binaries? (1.3+) | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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.
|
Copyright © 1999-2021 by the D Language Foundation