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.

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)

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.

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.

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?

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!

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

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.

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.

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.