On Tuesday, 15 May 2018 at 19:41:25 UTC, Rubn wrote:
> On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
>> [...]
>
> Which DMD version are you using to compile with?

dmd 2.080.0 installed today.

> Yah I have no idea how making the installer works

I know how it works, I just don't know how it built the dmd that it packaged.

> but it obviously isn't a works by default and needs to be built in a certain environment. There isn't any documentation on this as far as I know.

Martin posted somewhere about what was needed to build the installer. I can't remember where though, and it wouldn't be trivial to reproduce, let alone automate. In any case, I can't build it myself to find out.

> What I do is just grab what is built from appveyor and replace the dmd.exe that was installed using the installer. Worked a while back not sure if that's still the case:
>
> https://ci.appveyor.com/project/greenify/dmd/build/artifacts

I didn't know that was a thing - it might just be the way forward. Thanks!

Atila

On Tuesday, 15 May 2018 at 19:54:03 UTC, Ethan Watson wrote:
> On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
>> Isn't it just make -f win64.mak?", I hear you ask.
>
> I wouldn't ask that. Every time I need a 64-bit dmd, I open the project in src/vcbuild and let Visual Studio and Visual D take care of it.

Unfortunately, that doesn't work so well when one is trying to automate the provisioning of a Windows dev/CI box from scratch. I guess I could try msbuild on it...

> But I agree with the subject entirely. 64-bit DMD is absolutely required for my own usage. The Linux platforms have i386/x64 downloads. OSX is going 64-bit only. Having both packages available for Windows would be much appreciated.

I'm sure there's a good reason why there's no pre-built 64-bit dmd for Windows, I just don't know what it is.

On Tuesday, 15 May 2018 at 19:43:25 UTC, Walter Bright wrote:
> On 5/15/2018 9:01 AM, Atila Neves wrote:
>> I just spent 45min trying to build 64-bit dmd on Windows. It wasn't fun.
>
> Please file this post on bugzilla.

https://issues.dlang.org/show_bug.cgi?id=18864

On 5/15/2018 3:15 PM, Atila Neves wrote:
> https://issues.dlang.org/show_bug.cgi?id=18864

:-)

On 5/15/2018 3:13 PM, Atila Neves wrote:
> I'm sure there's a good reason why there's no pre-built 64-bit dmd for Windows, I just don't know what it is.

Part of it is there was no Win64 bit code generation capability for quite a while.

Then there was the issue of VC not supporting 80 bit reals.

But I think these are resolved now.

On Tue, 2018-05-15 at 17:40 +0000, 12345swordy via Digitalmars-d wrote:
> 
[…]
> Wait, dmd doesn't use cmake to generate the makefile!? IMO this is the reason why configuration tools like cmake exist.

Last time I mentioned updating any build systems in the D-verse, some people mentioned "try it and lets see" which is sensible, but most people said effectively "Make is the pinnacle of build you cannot dare suggest it is not the right tool for the job." which put me off sufficient to stop thinking about it.

Then we had the CMake/Meson/Reggae/Dub/SCons debate and it descended into a thread with so many not-relabelled sub-threads, and so long, I gave up. It seems whilst there are some people wanting to update the build, it generates sufficient noise that no-one individual or small group can be bothered to push through the inertia.

CMake could do the job despite being horrible. Meson is probably a better tool but it involves Ninja not Make. Reggae could do the job but suffers from not being a build tool in the top club, i.e. people do not think of it as an option since it has little traction. I am not sure if Dub could do the job. SCons could but I am probably one of the few in the D community who like it.

So as always inertia and the status quo win.


PS Given that I now mostly do Rust/Cargo/GTK/GStreamer stuff, I have stopped thinking about ways of doing builds of D codebases not using Dub, Scons, or Meson. It does make me wish Dub was more like Cargo than it is.

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tue, 2018-05-15 at 22:07 +0000, Atila Neves via Digitalmars-d wrote:
> On Tuesday, 15 May 2018 at 17:40:46 UTC, 12345swordy wrote:
> > On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
> > > [...]
> > 
> > Wait, dmd doesn't use cmake to generate the makefile!? IMO this is the reason why configuration tools like cmake exist.
> 
> CMake? Hah, no. They're hand crafted Makefiles written with quills.

Crickey, I thought they had been carved into the fabric of the Universe using stone tools.

;-)

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tuesday, 15 May 2018 at 19:41:25 UTC, Rubn wrote:
> On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
>> [...]
>
> Which DMD version are you using to compile with? There was an issue in DMD a while back that prevented the 64-bit version from being compiled.
>
> Yah I have no idea how making the installer works but it obviously isn't a works by default and needs to be built in a certain environment. There isn't any documentation on this as far as I know.
>
> What I do is just grab what is built from appveyor and replace the dmd.exe that was installed using the installer. Worked a while back not sure if that's still the case:
>
> https://ci.appveyor.com/project/greenify/dmd/build/artifacts

So... funny story. I did that and started randomly getting `dmd.exe failed with exit code -1073741819` error messages. Which just happens to be what I was seeing when I built it myself and tried using `-O` or removing `-debug`. So at least it's consistent?

Atila

On Wednesday, 16 May 2018 at 11:21:21 UTC, Atila Neves wrote:
> On Tuesday, 15 May 2018 at 19:41:25 UTC, Rubn wrote:
>> On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
>>> [...]
>>
>> Which DMD version are you using to compile with? There was an issue in DMD a while back that prevented the 64-bit version from being compiled.
>>
>> Yah I have no idea how making the installer works but it obviously isn't a works by default and needs to be built in a certain environment. There isn't any documentation on this as far as I know.
>>
>> What I do is just grab what is built from appveyor and replace the dmd.exe that was installed using the installer. Worked a while back not sure if that's still the case:
>>
>> https://ci.appveyor.com/project/greenify/dmd/build/artifacts
>
> So... funny story. I did that and started randomly getting `dmd.exe failed with exit code -1073741819` error messages. Which just happens to be what I was seeing when I built it myself and tried using `-O` or removing `-debug`. So at least it's consistent?
>
> Atila

Yah I think it was something like that, I'm using 32-bit so it has probably been like that for a while. Doesn't help that there is very little testing on Windows. There is testing done to make sure DMD works compiling several projects, but that's only done on Linux and not Windows/OSX.

On Tuesday, 15 May 2018 at 16:01:28 UTC, Atila Neves wrote:
> I just spent 45min trying to build 64-bit dmd on Windows. It wasn't fun. "Isn't it just make -f win64.mak?", I hear you ask. Yes. If you want a version with debug messages turned on. It took me 45min to learn that disabling those is... non-trivial.

I realize you all must be sick of me by now, but:

digger build --model=64

If you don't have Digger yet, you can run it straight from Dub:

dub fetch digger
dub run digger -- build --model=64