Running the DMD test suite on windows seems to be very rare and documentation appears to be non-existent. The following page (https://wiki.dlang.org/Building_under_Windows) would be a good place to hold such documentation.
I think the big issue with it is how to install Make/BASH. I've tried a few times to get these installed but failed, however, I think I may have been using a version that was too old. I'd ask that someone who has successfully gotten the test suite to run on windows share the steps they used on the wiki page.
There's also Martin's gist on how we bootstraps the Windows VirtualBoxes for the releases:
https://gist.github.com/MartinNowak/8270666/
(there are similar gists for FreeBSD and OSX)
Comment #3 by greensunny12 — 2018-03-24T15:13:49Z
BTW guys I just built the GNUmake exe via AppVeyor in case someone is looking for this:
https://issues.dlang.org/show_bug.cgi?id=18658https://github.com/dlang/installer/pull/311https://ci.appveyor.com/project/greenify/installer-gqmr6/build/1.0.16/artifacts
So far my steps for reproducing everything under Wine:
---
wget http://downloads.dlang.org/releases/2.x/2.079.0/dmd-2.079.0.exe
wine dmd-2.079.0.exe
---
(install dmc too)
Then export these variables:
---
export DM_HOME=C:/D
export HOST_DC=dmd
export WINEPATH="C:\DMC\dm\bin\;C:\D\dmd2\windows\bin"
---
With this I can build everything under Wine:
---
cd dmd
wine make -f win32.mak
cd ../druntime
wine make -f win32.mak
cd ../phobos
wine make -f win32.mak
---
Now for the testsuite. Here are my attempts:
---
cd dmd/test
wget https://ci.appveyor.com/api/buildjobs/twy5nix34sn0329n/artifacts/gmake-4.2.zip
unzip gmake-4.2.zip
wine make.exe
---
but that still fails:
---
...
CreateProcess(Z:\bin\bash,/bin/bash -c "echo \"Building d_do_test tool\"",...)
Putting child 001DA438 (test_results/d_do_test.exe) PID 1578448 on the chain.
Live child 001DA438 (test_results/d_do_test.exe) PID 1578448
Main thread handle = 00000040
make: *** WaitForMultipleObjects: No such file or directory. Stop.
make: *** Waiting for unfinished jobs....
Live child 001DA438 (test_results/d_do_test.exe) PID 1578448
make: *** WaitForMultipleObjects: No such file or directory. Stop.
---
I assume this is due to missing bash. Did either of you manage to install bash?
Last but not least, there's also:
https://github.com/braddr/at-client/blob/master/src/do_test_dmd.sh
I see cygpath there. So I maybe cygwin is needed to run DMD's testsuite?
Comment #4 by johnnymarler — 2018-03-24T15:23:58Z
Building DMD on linux with WINE is a good use case. However, that has a different set of problems than building on windows directly. Namely, how to build/install GNUmake and BASH.
Comment #5 by kinke — 2018-03-24T15:33:57Z
(In reply to Jonathan Marler from comment #4)
> Building DMD on linux with WINE is a good use case. However, that has a
> different set of problems than building on windows directly. Namely, how to
> build/install GNUmake and BASH.
GNU make comes with a Visual Studio solution; the LDC AppVeyor jobs use a prebuilt version of mine. bash is available as part of git for Windows (already installed on AppVeyor).
See https://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests for make download link etc.
Wrt. bash, I seem to recall that this line here was of importance (not in DMD's test makefile): https://github.com/ldc-developers/dmd-testsuite/blob/ldc/Makefile#L108
Comment #6 by slavo5150 — 2018-03-24T23:45:40Z
Building and testing D in a Bash environment on Windows is not ideal. It requires too many non-Windows dependencies and results in a testing environment different from the Windows-native environment that most users will be running their compiler and their programs from during "real" development.
We need something more Windows-native. IMO, it would be ideal if we could just write our build and test system in D, removing make and Bash altogether. The build-system will immediately be portable to any platform D supports and will reduce the skills required to maintain the build and test system from make, Bash, D, and C/C++ to just D and C/C++, with the latter requirement being removed when DMD's backend gets converted to D.
I maintain a few large projects in C#/C++ and their build, test, and publish systems are all custom built in C#. Due to .Net's huge library of features the code is only a few hundred lines, and is simple for anyone with C# skills to understand, which is already required to maintain the software being built anyway. It's always been somewhat ridiculous to me that developers use extremely expressive and powerful languages to develop their software, but choose to use restrictive, archaic when building that same software.