www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows devs - how are you building dmd, druntime, phobos?

reply Atila Neves <atila.neves gmail.com> writes:
For dmd, neither win32.mak or win64.mak work for me at all. I'm 
at a loss as to how they work for the autotester. Fortunately I 
learned about build.d on github, and that works fine.

But then I tried druntime and couldn't build that with the 
Windows makefile. There's no build.d there though, at least not 
with that name. The makefile seems to try creating directories 
more than once and fails.

Given all the above, how is that people on Windows manage to work 
on the 3 core D repos? I'm trying to fix the situation (mostly so 
I can get the dmd bash tests to run there), but first I'd like to 
know if I'm doing something wrong.

Bear in mind I've build all 3 repos repeatedly on Windows 
before...
Jul 25 2019
next sibling parent reply Ethan <gooberman gmail.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows 
 before...


I just pulled latest and did my usual "open src/vcbuild/dmd.sln" 
in Visual Studio. Hit compile.

'C:\Program' is not recognized as an internal or external 
command, operable program or batch file.

I think a recent Windows update has ruined how paths are reported 
in Visual Studio. Had to change some definitions in my own stuff 
that's been working for ages too.

Perhaps the makefiles are having the same problem.
Jul 25 2019
parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 25 July 2019 at 13:23:37 UTC, Ethan wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 [...]


 I just pulled latest and did my usual "open 
 src/vcbuild/dmd.sln" in Visual Studio. Hit compile.

 'C:\Program' is not recognized as an internal or external 
 command, operable program or batch file.

 I think a recent Windows update has ruined how paths are 
 reported in Visual Studio. Had to change some definitions in my 
 own stuff that's been working for ages too.

 Perhaps the makefiles are having the same problem.


That's... even worse. And I really don't want to have to open 
Visual Studio in the first place.
Jul 25 2019
prev sibling next sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.


I've never been able to figure it out.  My advice is don't even 
waste another moment trying to figure it out.  Just create a 
build.d file in Phobos and druntime right now and get busy.  It 
will be be a more time-consuming task (maybe a day or two), but 
it will be more satisfying, you'll learn a lot, and you'll be 
doing us all a most valuable service.

Mike
Jul 25 2019
prev sibling next sibling parent reply Exil <Exil gmall.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows 
 before...


Yup, welcome to hell. Everything is basically hidden behind 
configuration files somewhere in autotester. It took a long time 
to figure out how to compile DMD with VS. If you don't want to do 
it, good luck trying to figure out how to do it without VS.

To build phobos/druntime you actually need to remove a "/" from 
the environment variable, why was this done? Because fuck you 
that's why, no one on the D team is competent enough with Windows 
to make it work with the default expected value.

     cd $ROOT/src/druntime
     make -f win64.mak clean
     make -f win64.mak VCDIR="${VCINSTALLDIR::-1}" 
DMD=../dmd/src/dmd druntime32mscoff

     cd $ROOT/src/phobos
     make -f win64.mak clean
     make -f win64.mak VCDIR="${VCINSTALLDIR::-1}" 
DMD=../dmd/src/dmd phobos32mscoff


I also use git bash to run a .sh script since testing DMD 
requires shell scripts. Need to do a workaround with 
vcvarsall.bat so that it loads all the appropriate environment 
variables.

$ROOT is just the root directory that's set in the editor I use.

DMD requires all the repositories be in the same folder. So dmd, 
druntime, and phobos need to be in one folder.

Good luck!

Oh one more thing. DMD/Phobos/DRuntime use Digital Mars' MAKE to 
build with. While the testing suite uses GNU MAKE. Guess what D 
puts in your root path called "make", yup their digital mars' 
MAKE instead of what people would expect to be GNU Make (and 
those that do already have a GNU Make in their path). Why? 
Because fuck you.
Jul 25 2019
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:


 no one on the D team is competent enough with Windows to make 
 it work with the default expected value.


It's almost as if the people doing the work are volunteering 
their time to do it for the Windows developers that want it but 
aren't willing to do the work.
Jul 25 2019
parent reply Exil <Exil gmall.com> writes:
On Thursday, 25 July 2019 at 18:57:10 UTC, bachmeier wrote:

 On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:


 no one on the D team is competent enough with Windows to make 
 it work with the default expected value.


 It's almost as if the people doing the work are volunteering 
 their time to do it for the Windows developers that want it but 
 aren't willing to do the work.


Or someone already has made multiple pull requests and no one has 
merged them. I'm tired of hearing this shit. Why didn't they 
merge it? Because it breaks the shitty autotester/release build 
system. And guess who are the only ones that has access to 
configure the autotester/build server. Only one or a handful of 
people that don't give a shit to do the work to fix it. If they 
want to give me the logins and passwords to the autotester/build 
server, I will gladly fix it for them. And then there in lies the 
problem.
Jul 25 2019
next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 25 July 2019 at 19:31:26 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 18:57:10 UTC, bachmeier wrote:

 On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:


 no one on the D team is competent enough with Windows to make 
 it work with the default expected value.


 It's almost as if the people doing the work are volunteering 
 their time to do it for the Windows developers that want it 
 but aren't willing to do the work.


 Or someone already has made multiple pull requests and no one 
 has merged them. I'm tired of hearing this shit. Why didn't 
 they merge it? Because it breaks the shitty autotester/release 
 build system. And guess who are the only ones that has access 
 to configure the autotester/build server. Only one or a handful 
 of people that don't give a shit to do the work to fix it. If 
 they want to give me the logins and passwords to the 
 autotester/build server, I will gladly fix it for them. And 
 then there in lies the problem.


Actually it's only a single person who has access to the 
Auto-Tester. All other CIs are configured via their in-source 
YAMLs though. Also, the Auto-Tester just runs a defined Makefile 
target, so it's not too hard to fix things with a single PR.
Jul 25 2019
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 25 July 2019 at 20:48:43 UTC, Seb wrote:

 On Thursday, 25 July 2019 at 19:31:26 UTC, Exil wrote:

 [...]


 Actually it's only a single person who has access to the 
 Auto-Tester. All other CIs are configured via their in-source 
 YAMLs though. Also, the Auto-Tester just runs a defined 
 Makefile target, so it's not too hard to fix things with a 
 single PR.


The problem was at one point he was applying patch files to some 
of the files in DMD.  I hope that has been removed at this point?
Jul 25 2019
parent Seb <seb wilzba.ch> writes:
On Thursday, 25 July 2019 at 21:10:02 UTC, Jonathan Marler wrote:

 On Thursday, 25 July 2019 at 20:48:43 UTC, Seb wrote:

 On Thursday, 25 July 2019 at 19:31:26 UTC, Exil wrote:

 [...]


 Actually it's only a single person who has access to the 
 Auto-Tester. All other CIs are configured via their in-source 
 YAMLs though. Also, the Auto-Tester just runs a defined 
 Makefile target, so it's not too hard to fix things with a 
 single PR.


 The problem was at one point he was applying patch files to 
 some of the files in DMD.  I hope that has been removed at this 
 point?


No it's still there. Though it has been removed for druntime and 
Phobos which was were it caused the problems and the diff for dmd 
is now only a single file diff:

https://github.com/braddr/at-client/blob/master/src/do_fixup.sh
https://github.com/braddr/at-client/blob/master/src/diff-dmd-win64.diff
https://github.com/braddr/at-client/commit/8a2a2743716fcfde13d5ab0856bd4b5a0e403851
Jul 25 2019
prev sibling parent reply Exil <Exil gmall.com> writes:
On Thursday, 25 July 2019 at 20:48:43 UTC, Seb wrote:

 All other CIs are configured via their in-source YAMLs though.


Yes because then contributors can actually make changes to the 
environment through the config files. Not like the stone-age 
autotester.


 Also, the Auto-Tester just runs a defined Makefile target, so 
 it's not too hard to fix things with a single PR.


This doesn't ensure the proper tools are installed. Like for 
example, if you wanted to build DMD with LDC2. Can't do that 
unless you have LDC2 installed on the machine. Can't install LDC2 
on the machine without having access to it to do so.

It'll literally be playing trial and error either way to ensure 
it is working, without something that is being used.

Those patch just, yah... I don't even know what to say about 
that. Hell of a workaround.
Jul 25 2019
parent Seb <seb wilzba.ch> writes:
On Friday, 26 July 2019 at 00:43:42 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 20:48:43 UTC, Seb wrote:

 All other CIs are configured via their in-source YAMLs though.


 Yes because then contributors can actually make changes to the 
 environment through the config files. Not like the stone-age 
 autotester.


 Also, the Auto-Tester just runs a defined Makefile target, so 
 it's not too hard to fix things with a single PR.


 This doesn't ensure the proper tools are installed. Like for 
 example, if you wanted to build DMD with LDC2. Can't do that 
 unless you have LDC2 installed on the machine. Can't install 
 LDC2 on the machine without having access to it to do so.


Well, we already build DMD with LDC (on SemaphoreCI for Linux and 
Azure Pipelines for Windows). And of those machines we just 
download the LDC2 binaries, so no sudo installation required 
there. I see your point for e.g. newer compiler releases though, 
but all compiler/OS combinations on the auto-tester are still 
officially supported.

We would like to replace the auto-tester, but so far no one else 
has been willing to commit/donate the resources to do so (see the 
fully dedicated build hosts it has: 
https://auto-tester.puremagic.com/hosts).
Anyhow, even if people complain about it every now and then, it's 
still surprisingly stable.
Jul 26 2019
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 25 July 2019 at 19:31:26 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 18:57:10 UTC, bachmeier wrote:

 On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:


 no one on the D team is competent enough with Windows to make 
 it work with the default expected value.


 It's almost as if the people doing the work are volunteering 
 their time to do it for the Windows developers that want it 
 but aren't willing to do the work.


 Or someone already has made multiple pull requests and no one 
 has merged them. I'm tired of hearing this shit. Why didn't 
 they merge it? Because it breaks the shitty autotester/release 
 build system. And guess who are the only ones that has access 
 to configure the autotester/build server. Only one or a handful 
 of people that don't give a shit to do the work to fix it. If 
 they want to give me the logins and passwords to the 
 autotester/build server, I will gladly fix it for them. And 
 then there in lies the problem.


My response was to your criticism of their lack of competence: 
"no one on the D team is competent enough with Windows to make it 
work with the default expected value." I wasn't responding to a 
complaint about their unwillingness to merge pull requests.
Jul 25 2019
parent Exil <Exil gmall.com> writes:
On Friday, 26 July 2019 at 02:32:50 UTC, bachmeier wrote:

 On Thursday, 25 July 2019 at 19:31:26 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 18:57:10 UTC, bachmeier wrote:

 On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:


 no one on the D team is competent enough with Windows to 
 make it work with the default expected value.


 It's almost as if the people doing the work are volunteering 
 their time to do it for the Windows developers that want it 
 but aren't willing to do the work.


 Or someone already has made multiple pull requests and no one 
 has merged them. I'm tired of hearing this shit. Why didn't 
 they merge it? Because it breaks the shitty autotester/release 
 build system. And guess who are the only ones that has access 
 to configure the autotester/build server. Only one or a 
 handful of people that don't give a shit to do the work to fix 
 it. If they want to give me the logins and passwords to the 
 autotester/build server, I will gladly fix it for them. And 
 then there in lies the problem.


 My response was to your criticism of their lack of competence: 
 "no one on the D team is competent enough with Windows to make 
 it work with the default expected value." I wasn't responding 
 to a complaint about their unwillingness to merge pull requests.


Being competent and doing work is two different things. The 
work's been done, it just wasn't done by someone competent. I 
don't know what you are going on about. Try using more than one 
single run-on sentence.
Jul 29 2019
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:



 I also use git bash to run a .sh script since testing DMD 
 requires shell scripts. Need to do a workaround with 
 vcvarsall.bat so that it loads all the appropriate environment 
 variables.


Wait... you can run the dmd shell tests with git bash?? That's 
exactly what I was trying to enable! Any chance you can submit a 
PR? Thanks!
Jul 26 2019
parent Exil <Exil gmall.com> writes:
On Friday, 26 July 2019 at 12:00:25 UTC, Atila Neves wrote:

 On Thursday, 25 July 2019 at 14:11:34 UTC, Exil wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:



 I also use git bash to run a .sh script since testing DMD 
 requires shell scripts. Need to do a workaround with 
 vcvarsall.bat so that it loads all the appropriate environment 
 variables.


 Wait... you can run the dmd shell tests with git bash?? That's 
 exactly what I was trying to enable! Any chance you can submit 
 a PR? Thanks!



You need the VS symbols so I have a "run.cmd" file which forwards 
the environment variables to git bash.

     "C:\\Program Files (x86)\\Microsoft Visual Studio 
14.0\\VC\\vcvarsall.bat" x64 && "C:\\Program 
Files\\Git\\bin\\bash.exe" build.sh


Then build.sh is the following:

     cd $ROOT/src/dmd/test
     gnumake -j4 quick LIB="../../phobos;$LIB" MODEL=64 
DMD_MODEL=64

Need to add the actual GNU make to your PATH variable as well.

Each time I need to build/run the tests though, there is a new 
problem because the files are always changing. And they only test 
for whatever narrow circumstances they are using it with. I've 
had problems building/running the "run.d" file, forget what it 
was that fixed it. Don't know if it is still an issue now. It's a 
pain in the ass.
Jul 28 2019
prev sibling next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows 
 before...


Almost every time I build under windows I end up having to Google 
"dlang dmd build under windows" and click on the wiki page to 
refresh my memory on how to do it. There are alot of steps.

For example, you have to have a particular directory structure 
that's deeper than a Linux build, and you need to set DM_HOME and 
HOST_DC and you need to make sure you're using DigitalMars make 
rather than gnu make.
Jul 25 2019
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows 
 before...


I used to build very often on Windows. I'll give it a try tonight 
and report back.
Jul 25 2019
next sibling parent a11e99z <black80 bk.ru> writes:
On Thursday, 25 July 2019 at 16:09:37 UTC, Meta wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 I used to build very often on Windows. I'll give it a try 
 tonight and report back.


if you succeed with building please add shared option for RT & 
Phobos too
Jul 25 2019
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 25 July 2019 at 16:09:37 UTC, Meta wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. 
 I'm at a loss as to how they work for the autotester. 
 Fortunately I learned about build.d on github, and that works 
 fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least 
 not with that name. The makefile seems to try creating 
 directories more than once and fails.

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows 
 before...


 I used to build very often on Windows. I'll give it a try 
 tonight and report back.


Well, better late than never. I made a fresh clone of dmd's repo 
and first tried building 64-bit dmd. All I had to do was the 
following:

git clone https://github.com/dlang/dmd.git
cd dmd
make -fwin64.mak
(Note you also need to define HOST_DC in your enviroment)

HOWEVER, it failed halfway through building:

std.process.ProcessException std\process.d(754): Failed to spawn 
new process (The system cannot find the file specified.)
----------------
0x0040B0FC in  trusted std.process.Pid 
std.process.spawnProcessImpl(scope const(char)[], std.stdio.File, 
std.stdio.File, std.stdio.File, 
const(immutable(char)[][immutable(char)[]]), std.process.Config, 
const(char)[])
0x00405564 in  trusted std.process.Pid 
std.process.spawnProcess(scope const(char[])[], std.stdio.File, 
std.stdio.File, std.stdio.File, 
const(immutable(char)[][immutable(char)[]]), 
std.process.Configconst , char[])
0x00402547 in _Dmain
0x00404A0F in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll().__lambda1()
0x00404991 in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll()
0x0040482A in _d_run_main
0x004045DC in main at F:\repos\dmd\src\vcbuild\msvc-lib.d(7)
0x0044E799 in mainCRTStartup
0x779A0419 in BaseThreadInitThunk
0x77C7662D in RtlGetAppContainerNamedObjectPath
0x77C765FD in RtlGetAppContainerNamedObjectPath

--- errorlevel 1

--- errorlevel 1

--- errorlevel 1

--- errorlevel 1



I'm hitting this same error with 32-bit dmd.


I also triedVisual Studio project, and it built dmd with no 
problems whatsoever.
Jul 27 2019
next sibling parent Ethan <gooberman gmail.com> writes:
On Saturday, 27 July 2019 at 21:39:46 UTC, Meta wrote:

 I also triedVisual Studio project, and it built dmd with no 
 problems whatsoever.


I've discovered that the problem I'm having is the custom build 
step expects the $(_DCompilerExe) token to be in a folder without 
spaces. I'll submit a pull request for that soon.

I've also found a bug in Visual D where it can't generate the 
correct paths and thus fails to link in phobos. But I'm not 100% 
on what token is the problem there.

Needless to say, I'm building 32- and 64-bit executables again.
Jul 27 2019
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Saturday, 27 July 2019 at 21:39:46 UTC, Meta wrote:

 git clone https://github.com/dlang/dmd.git
 cd dmd
 make -fwin64.mak
 (Note you also need to define HOST_DC in your enviroment)

 HOWEVER, it failed halfway through building:

 std.process.ProcessException std\process.d(754): Failed to 
 spawn new process (The system cannot find the file specified.)


You need to define DMD too, see e.g. 
https://github.com/dlang/dmd/blob/master/.azure-pipelines/windows.sh#L72

tl;dr:
- Use src/build.d when you want to build locally.
- You can grab a DMD 64-bit executable on Azure:

https://dev.azure.com/dlanguage/dmd/_build?definitionId=1&_a=summary

e.g. 
https://dev.azure.com/dlanguage/dmd/_build/results?buildId=3720
Jul 27 2019
prev sibling parent Suleyman <sahmi.soulaimane gmail.com> writes:
On Saturday, 27 July 2019 at 21:39:46 UTC, Meta wrote:

 [...]
 HOWEVER, it failed halfway through building:

 [...]


You have to define MSVC_AR for example in cmd `set 
MSVC_AR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\lib.exe`
Aug 02 2019
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the 
 Windows makefile. There's no build.d there though, at least not 
 with that name. The makefile seems to try creating directories 
 more than once and fails.


Yup, I never got around creating build.d for druntime and Phobos 
and it looks like no one else has the motivation/time to do so 
either.


 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.


They use digger or (for the most part) give up building it on 
Windows.
In case you are interested here are the steps required:

https://github.com/dlang/dmd/blob/master/.azure-pipelines/windows.sh (<- this
is run by our CI)

https://wiki.dlang.org/Building_under_Windows
Jul 25 2019
parent Meta <jared771 gmail.com> writes:
On Thursday, 25 July 2019 at 16:14:03 UTC, Seb wrote:

 In case you are interested here are the steps required:

 https://github.com/dlang/dmd/blob/master/.azure-pipelines/windows.sh (<- this
is run by our CI)

 https://wiki.dlang.org/Building_under_Windows


I believe these are the steps I used the last time I built 
dmd/druntime/phobos (sometime last December IIRC).
Jul 25 2019
prev sibling next sibling parent Martin Krejcirik <mk-junk i-line.cz> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.


win32.mak works fine for me with proper paths to dmd and dmc.
build.d or win64.mak doesn't work at all for me. I'm using 
minimal visual studio install (VS build tools, or how is it 
called). However for 32 bit build it's not needed.

Druntime compilation fails since dmd 2.085 on some internal error 
(assert failure).

---
ERROR: This is a compiler bug.
Please report it via https://issues.dlang.org/enter_bug.cgi
with, preferably, a reduced, reproducible example and the 
information below.
DustMite (https://github.com/CyberShadow/DustMite/wiki) can help 
with the reduction.
---
DMD v2.085.1

predefs   DigitalMars Windows CRuntime_DigitalMars 
CppRuntime_DigitalMars LittleEndian D_Version2 all D_InlineAsm 
D_InlineAsm_X86 X86 Win32 D_ModuleInfo D_Exceptions D_TypeInfo 
D_HardFloat
binary    
D:\Programs\dmd2.src\src\generated\windows\release\32\dmd.exe
version   v2.085.1

config
DFLAGS    (none)
---

core.exception.AssertError dmd\dsymbolsem.d(3344): Assertion 
failure
----------------
0x00605363 in _d_assertp
0x00461332 in DsymbolSemanticVisitor at 
D:\Programs\dmd2.src\src\dmd\dmd\dsymbolsem.d(3695)
0x004A5C4D in FuncDeclaration at 
D:\Programs\dmd2.src\src\dmd\dmd\func.d(2405)
0x00458E0C in dsymbolSemantic at 
D:\Programs\dmd2.src\src\dmd\dmd\dsymbolsem.d(366)
0x0045C00A in DsymbolSemanticVisitor at 
D:\Programs\dmd2.src\src\dmd\dmd\dsymbolsem.d(1574)
0x0045C05A in DsymbolSemanticVisitor at 
D:\Programs\dmd2.src\src\dmd\dmd\dsymbolsem.d(1586)
0x004F86F9 in ParseTimeVisitor at 
D:\Programs\dmd2.src\src\dmd\dmd\parsetimevisitor.d(73)
0x0040996D in StorageClassDeclaration at 
D:\Programs\dmd2.src\src\dmd\dmd\attrib.d(306)
0x00458E0C in dsymbolSemantic at 
D:\Programs\dmd2.src\src\dmd\dmd\dsymbolsem.d(366)
Jul 25 2019
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 Given all the above, how is that people on Windows manage to 
 work on the 3 core D repos? I'm trying to fix the situation 
 (mostly so I can get the dmd bash tests to run there), but 
 first I'd like to know if I'm doing something wrong.


IIRC all three built for me as 32-bit but not 64-bit last time I 
tried (but it's been a while). Usually I don't bother to build 
everything, I just `dmd -unittest -main -g -run std.xxx` when 
contributing stuff to Phobos. I don't recall having ever ran the 
full test suite myself. I just commit and hope it passes the 
autotester :D. I quess that we're even more reliant on the 
autotester than it would first appear!
Jul 25 2019
prev sibling next sibling parent reply John Burton <john.burton jbmail.com> writes:
On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm 
 at a loss as to how they work for the autotester. Fortunately I 
 learned about build.d on github, and that works fine.


Last week I had a little spare time and thought I'd see if I could
fix a very minor issue in D that I reported a while back. It 
turned out
to be in druntime. I tried for several hours to build my changes 
in druntime
and dmd using windows and various sets of instructions and trying 
to work the
process out for myself but nothing seemed to work and eventually 
I gave up.

The experience didn't exactly encourage me to go further with D 
although I
understand it's not a priority for anyone to work on (and I still 
think D and
it's community are generally great) so I'm not giving up (and 
would still like
to know how to successfully build my changes on windows)
Jul 26 2019
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Friday, 26 July 2019 at 12:12:10 UTC, John Burton wrote:

 On Thursday, 25 July 2019 at 13:12:58 UTC, Atila Neves wrote:

 [...]


 Last week I had a little spare time and thought I'd see if I 
 could
 fix a very minor issue in D that I reported a while back. It 
 turned out
 to be in druntime. I tried for several hours to build my 
 changes in druntime
 and dmd using windows and various sets of instructions and 
 trying to work the
 process out for myself but nothing seemed to work and 
 eventually I gave up.

 The experience didn't exactly encourage me to go further with D 
 although I
 understand it's not a priority for anyone to work on (and I 
 still think D and
 it's community are generally great) so I'm not giving up (and 
 would still like
 to know how to successfully build my changes on windows)


I'm working on it. Making some PRs to transition the build to D 
and consolidate the windows and posix builds. Hopefully it will 
be a lot better soon.
Jul 26 2019
prev sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Jul 25, 2019 at 6:15 AM Atila Neves via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 For dmd, neither win32.mak or win64.mak work for me at all. I'm
 at a loss as to how they work for the autotester. Fortunately I
 learned about build.d on github, and that works fine.

 But then I tried druntime and couldn't build that with the
 Windows makefile. There's no build.d there though, at least not
 with that name. The makefile seems to try creating directories
 more than once and fails.

 Given all the above, how is that people on Windows manage to work
 on the 3 core D repos? I'm trying to fix the situation (mostly so
 I can get the dmd bash tests to run there), but first I'd like to
 know if I'm doing something wrong.

 Bear in mind I've build all 3 repos repeatedly on Windows
 before...


I build DMD with the VS project (or msbuild from terminal).
I build and test druntime by executing the lines at the bottom on
appveyor.yml, same as the CI.
Jul 26 2019