Fix win32.mak to match posix hierarchy

[RazvanN7]

Currently BUILD is hardcoded to release. Since the windows make tool is pretty dumb, it should suffice for now

[RazvanN7]

ping @braddr @andralex @wilzbach

[andralex]

Cool, now please follow up with updates to the testing scripts.

[mathias-lang-sociomantic]

Will that pose any problem for Digger ? @CyberShadow ?

[CyberShadow]

Will that pose any problem for Digger ?

Not as long as it creates a src\dmd.exe as before.

[RazvanN7]

@CyberShadow We should update digger to use the executable in generated/ because subject of the follow up PR is going to be to delete the executable in src

[CyberShadow]

No problem, ping me when you make that PR

[wilzbach]

Since the windows make tool is pretty dumb

Yeah about that ... how feasible would it be to replace DigitalMars make with GNUMake on Windows? It would at least save us the huge pain of maintaining different files for the same thing...
AFAICT is DigitalMars​ make part of the Windows release? Could it be swapped or are there licensing problems with bundling GNUMake?
I don't use Windows, but it seems that they offer prebuilt releases:

http://gnuwin32.sourceforge.net/packages.html

In the worst case we could use the Windows Makefiles & DigitalMars make to bootstrap GNUMake ...

[CyberShadow]

Yeah about that ... how feasible would it be to replace DigitalMars make with GNUMake on Windows? It would at least save us the huge pain of maintaining different files for the same thing...

I looked into that a while ago, for dlang.org. Essentially it would put us halfway there - GNU make is only half useful without the other GNU utilities, such as cp, rm etc. Without those, we would likely still need to maintain separate makefiles, or use lots of careful macros to use each platform's native OS/filesystem commands.

[CyberShadow]

This pull request introduced a regression:
https://issues.dlang.org/show_bug.cgi?id=17522

[wilzbach]

GNU make is only half useful without the other GNU utilities, such as cp, rm etc. Without those, we would likely still need to maintain separate makefiles, or use lots of careful macros to use each platform's native OS/filesystem commands.

Hmm couldn't we download the coreutils on windows too?
Heck, as we only need a specific subsets, we might even be able to implement them in D, e.g. for rm:

void main(string[] args)
{
    import std.file, std.getopt;
    bool recursive;
    auto config = getopt(args, "-r", recursive);
    foreach (arg; arg[1 .. $])
    {
        if (recursive) arg.rmdirRecurse;
        else arg.remove;
    }
}

[CyberShadow]

Hmm couldn't we download the coreutils on windows too?

Requiring a (any) POSIX toolchain on Windows (Cygwin, GnuWin32, MinGW, msys2, etc.) is one possibility of going forward and away from win32/64.mak.

Heck, as we only need a specific subsets, we might even be able to implement them in D

Yes. One idea is to implement them directly in DigitalMars Make (as built-ins).