Have Win DMD use gmake instead of a separate DMMake makefile?

[Walter Bright]

On 8/13/2013 2:55 AM, Joakim wrote:
> On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote:
>> On 8/12/2013 11:48 PM, Jacob Carlborg wrote:
>>> On 2013-08-13 02:42, Andrei Alexandrescu wrote:
>>>
>>>> Is is possible from a licensing standpoint to just distribute a copy of
>>>> gmake built by gnuwin?
>>>
>>> I don't see why we couldn't do that. It's a completely separate tool and
>>> shouldn't "infect" anything else. We might need to accompany it with a license
>>> file and a link to the source code to be on the safe side.
>>>
>>
>> Again, read my reply to Brad in this thread.
>
> Presumably you are referring to this quote, which does not show up as a reply?

Nobody seems to have read it or be able to find it, it has no replies, so I 
quote it here:
============================================================
n 8/11/2013 11:49 AM, Brad Roberts wrote:
 > Gross over generalization when talking about _one_ app in _one_ scenario.

It happens over and over to me. Most 'ports' to Windows seem to be:

1. get it to compile
2. ship it!


 > You're deflecting rather than being willing to discuss a topic that comes up
 > regularly.

I'm posting in this thread because I'm willing to discuss it. I've added much 
more detail in this post.


 > You are also well aware of just how often having multiple make files
 > has cause pain by them not being updated in sync.

Yes, and I am usually the one who gets to resync them - and I think it's worth it.


 > Does gmake have _any_ of those problems?

The last time I tried it, it bombed because the makefiles had CRLF's. Not an 
auspicious start. This has probably been fixed, but I haven't cared to try 
again. But ok, it's been a while, let's take a look:

Consider:

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

In the first paragraph, it says the user must have msvcrt.dll, which doesn't 
come with it and the user must go find it if he doesn't have it. Then "some 
packages require msvcp60.dll", which the user must also go find elsewhere.

Then, it must be "installed". It even is complicated enough to motivate someone 
to write a "download and maintenance utility."

"Some packages must be installed in their default directories (usually 
c:\progra~1\<packagename>), or you have to set corresponding environment 
variables or set options at the command line; see the documentation of the 
package, or, when available, the installation instructions on the package page."

Oh joy. I downloaded the zip file, unzipped it, and ran make.exe. I was rewarded 
with a dialog box:

"The program can't start because libintl3.dll is missing from your computer. Try 
reinstalling the program to fix this problem."

This dll isn't included with the zip file, and the install instructions don't 
mention it, let alone where I can get it.

"The length of the command-line is limited; see MSDN."

DM make solves that problem.

"The MS-Windows command interpreters, command.com and cmd.exe, understand both 
the backward slash '\' (which is the default) and the forward slash '/' (such as 
on Unix) in filenames. In general, it is best to use forward slashes, since some 
programs internally use the filename, e.g. to derive a directory name, and in 
doing this rely on the forward slash as path separator."

Actually, Windows utilities (even ones provided by Microsoft) sometimes fail to 
recognize / as a separator. I've not found any consistent rule about this, other 
than "it's going to suck sooner or later if you try using / instead of \."

I didn't get further, because I don't have libintl3.dll.

------------------------------

Contrast that with DM make:

1. There is no install and no setup. It's just make.exe. Run it, it works. No 
friction.

2. Don't need no dlls one must search the internet for, and also no worries 
about "dll hell" from getting the wrong one. DM make runs on a vanilla install 
of Windows.

3. It's designed from the ground up to work with Windows. For example, it 
recognizes "del" as a builtin Windows command, not a program, and handles it 
directly. It does things in the Windows way.

4. It handles arbitrarily long command lines.

5. No worries with people having a different make.exe than the one the makefiles 
were built for, as make.exe is distributed with dmd.

6. It's a small program, 50K, meaning it fits in a corner and is a trivial part 
of the dmd package.

------------------------------

If for no other reason, I oppose using gnu make for dmd on Windows because it 
significantly raises the barrier of entry for anyone who wants to just recompile 
Phobos. Gratuitously adding friction for users is not what we need - note the 
regular posts we get from newbies and the existing friction they encounter.