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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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