Dne 16.11.2016 v 04:17 rikki cattermole via Digitalmars-d napsal(a):
> On 16/11/2016 3:41 AM, Daniel Kozak via Digitalmars-d wrote:
>> Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):
>>
>>> On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
>>>> On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
>>>>> Are there plans to write a homebrew 64-bit linker for DMD?
>>>>
>>>> There are already ld from mingw and lld from llvm team.
>>>
>>> Why aren't they used and distributed in DMD for Windows by default?
>>>
>>> If the tools mentioned above (LD and LLD) are available and usable on
>>> Windows x64 instead of the ones provided in heavily bloated packages
>>> by Microsoft, how come the DMD installer for Windows doesn't offer
>>> them as an alternative (or better yet as the default)?
>>>
>> AFAIK ld on mingw can`t link against mscoff file format so it is not
>> very usable. LLD is quite new so I do not know how production ready is.
>> But I believe LLD will be the answer in future.
>
>
> From what I've read about LLD (~ 6+ months ago) the Windows implementation was a complete rewrite from the Linux support.
> It most definitely isn't production ready or we would have heard about it (after all e.g. OSX will want to shift over to it).
http://www.phoronix.com/scan.php?page=news_item&px=LLVM-LD-Linker-Default-Discuss
But I guess they are speaking about linux, freebsd and maybe OSX

On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak wrote:
> AFAIK ld on mingw can`t link against mscoff file format so it is not very usable.

It's dmd/optlink that don't support mscoff, mingw supports only mscoff.

> LLD is quite new so I do not know how production ready is.

AFAIK that's only because of lack of support for debug info. The rest works.

> Btw. today I want to start working on a D project in work, but I cant, because there is not enoght space on C:\ partion and there is not possible to instal VS to another disk :( (Ok in few attempt of installing VS there has been path I can change but it does not work anyway, still VS is trying to install to C:\ ).

My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.

On Wednesday, 16 November 2016 at 09:21:18 UTC, Kagamin wrote:
> On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak wrote:
>> AFAIK ld on mingw can`t link against mscoff file format so it is not very usable.
>
> It's dmd/optlink that don't support mscoff, mingw supports only mscoff.
>
>> LLD is quite new so I do not know how production ready is.
>
> AFAIK that's only because of lack of support for debug info. The rest works.
>
>> Btw. today I want to start working on a D project in work, but I cant, because there is not enoght space on C:\ partion and there is not possible to instal VS to another disk :( (Ok in few attempt of installing VS there has been path I can change but it does not work anyway, still VS is trying to install to C:\ ).
>
> My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.

Another issue I had with the Microsoft Package besides the size it wants on the system drive is the difficulty to even get it to download behind a corporate proxy. It took me hours to find a disk image version of the (free) visual stuff on the rotten Microsoft sites.
I get the technical reasons for using the MS toolchain but that doesn't change the fact that it is an ugly wart that has several negative aspect. Because in addition to the cases already described where it can be a pita to install there's also an image problem with that approach. dmd's adoption had always suffered from the closed source licence of the backend with one small company, adding a second depency, furthermore on a company not specially known for its openess (yeah, I know that it's a little bit better now) will raise criticism.
This issue is not big but it is definitely a - point when one makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)

On Wednesday, 16 November 2016 at 17:06:37 UTC, Patrick Schluter wrote:
> On Wednesday, 16 November 2016 at 09:21:18 UTC, Kagamin wrote:
>> On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak wrote:
>>> AFAIK ld on mingw can`t link against mscoff file format so it is not very usable.
>>
>> It's dmd/optlink that don't support mscoff, mingw supports only mscoff.
>>
>>> LLD is quite new so I do not know how production ready is.
>>
>> AFAIK that's only because of lack of support for debug info. The rest works.
>>
>>> Btw. today I want to start working on a D project in work, but I cant, because there is not enoght space on C:\ partion and there is not possible to instal VS to another disk :( (Ok in few attempt of installing VS there has been path I can change but it does not work anyway, still VS is trying to install to C:\ ).
>>
>> My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.
>
> Another issue I had with the Microsoft Package besides the size it wants on the system drive is the difficulty to even get it to download behind a corporate proxy. It took me hours to find a disk image version of the (free) visual stuff on the rotten Microsoft sites.
> I get the technical reasons for using the MS toolchain but that doesn't change the fact that it is an ugly wart that has several negative aspect. Because in addition to the cases already described where it can be a pita to install there's also an image problem with that approach. dmd's adoption had always suffered from the closed source licence of the backend with one small company, adding a second depency, furthermore on a company not specially known for its openess (yeah, I know that it's a little bit better now) will raise criticism.
> This issue is not big but it is definitely a - point when one makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)

Ok, I checked for Rust. They have 2 ABI versions one with MSVC and the other for gcc in 32 and 64 bits. MSVC ABI requires the same build tools from Microsoft, so the situation is the same there.
go doesn't need the MS tools apparently.

On Wednesday, 16 November 2016 at 17:06:37 UTC, Patrick Schluter wrote:

> I get the technical reasons for using the MS toolchain but that doesn't change the fact that it is an ugly wart that has several negative aspect. Because in addition to the cases already described where it can be a pita to install there's also an image problem with that approach. dmd's adoption had always suffered from the closed source licence of the backend with one small company, adding a second depency, furthermore on a company not specially known for its openess (yeah, I know that it's a little bit better now) will raise criticism.
> This issue is not big but it is definitely a - point when one makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)

Why is it a wart? The MS toolchain is the system development environment for Windows. On Mac OS X, it's Xcode, which is a 1+ GB download before you can do any development with clang or dmd or anything that depends on it. On Linux distros, if it the GCC packages aren't already installed, they need to be pulled down.

I mean, I get that the MS tools might not be perceived by some as the 'system' tools, but that is what they are. It's no different than the other systems DMD is distributed on.

On 2016-11-14 09:05, Nick Sabalausky wrote:

> The Linux and Mac versions rely on Linux/Mac's native C linkers,
> regardless of 32/64 bit.

Yeah. On macOS, Xcode is a 4.x GB download size and 12 GB install size (just looking at what I currently have).

Perhaps we should take the missing parts from the ELLCC tool chain [1]. It's a cross-compiler tool chain based on LLVM. It contains a compiler, linker, C/C++ standard library, other binutils and is completely self contained.

[1] http://ellcc.org

-- 
/Jacob Carlborg

On 2016-11-14 08:59, Nick Sabalausky wrote:

> I still have an "old fashioned" HDD-only in my PC (a laptop):
> dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares),
> and the ONLY time I ever have speed issues in either Win or Lin is when
> I'm running far too much crap and start hitting virtual memory swapping
> (or when some badly coded program soaks up all the CPU recourses, but
> SSDs cant help with that anyway).

I bought an SSD drive around a year ago. It was one of the biggest performance boosts I've seen in a computer. Boot times went from minutes to seconds.

-- 
/Jacob Carlborg

On 2016-11-16 09:19, Patrick Schluter wrote:

> go doesn't need the MS tools apparently.

As far as I know Go uses static linking and contains its own linker.

-- 
/Jacob Carlborg

On Wednesday, 16 November 2016 at 04:04:05 UTC, rikki cattermole wrote:
>
> And then we'll get complaints that they need another big download just to compile basic 32bit programs... This whole argument about making changes is rediculas.
>
> Unless we get explicit permission from Microsoft to distribute the parts we needs, I think it is safe to say that Optlink stays, in fact  nothing will change.

So just make it a switch. It's fine for anyone wanting to just try it, but for everyone else they probably already have to download Visual Studio.

On Wednesday, 16 November 2016 at 17:19:28 UTC, Patrick Schluter wrote:
>> Another issue I had with the Microsoft Package besides the size it wants on the system drive is the difficulty to even get it to download behind a corporate proxy.

Doesn't it pick whatever is configured in the system settings?

>> makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)

They probably don't depend on C runtime as much.
Scala?

> Ok, I checked for Rust. They have 2 ABI versions one with MSVC and the other for gcc in 32 and 64 bits. MSVC ABI requires the same build tools from Microsoft, so the situation is the same there.

LDC once supported mingw, but it broke. Most stuff should be still there.