On 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.
