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!

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)

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.

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.

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.

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.

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

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.

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.

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`