On Saturday, August 10, 2013 22:48:14 Walter Bright wrote:
> On 8/10/2013 4:21 PM, Jonathan M Davis wrote:
> > Another suggestion that I kind of liked was to just build them all with a single script written in D and ditch make entirely, which would seriously reduce the amount of duplication across platforms. But that's obviously a much bigger change and would likely be much more controversial than simply using a more standard make.
> 
> I don't see much point in that. The dmd build is straightforward, and I see no particular gain from reinventing that wheel.

Well, make is horrible, and while posix.mak is way better than win32.mak or win64.mak, it's still pretty bad. Personally, I would never use make without something like cmake in front of it. If we were to write up something in D, it could be properly cross-platform (so only one script instead of 3+), and I fully expect that it could be far, far cleaner than what we're forced to do in make.

- Jonathan M Davis

On Sat, 10 Aug 2013 22:48:14 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 8/10/2013 4:21 PM, Jonathan M Davis wrote:
> > On Saturday, August 10, 2013 14:35:04 Nick Sabalausky wrote:
> >> Is this something that would be acceptable, or does building DMD for Windows need to stay as DM make?
> >
> > I don't see any problem with it, but that doesn't mean that Walter won't.
> 
> Tools built for Unix never work right on Windows. It's why, for example, I run git on Linux and don't use the Windows badly ported versions of git. Tiresome problems revolve around failure to adapt to \ path separators, ; in PATH, CRLF line endings, Windows SEH, case insensitive file names, no symbolic links, etc., no Perl installed, etc.
> 

Fair point.

> 
> > Another suggestion that I kind of liked was to just build them all with a single script written in D and ditch make entirely, which would seriously reduce the amount of duplication across platforms. But that's obviously a much bigger change and would likely be much more controversial than simply using a more standard make.
> 
> I don't see much point in that. The dmd build is straightforward, and I see no particular gain from reinventing that wheel.
> 

The current state is fairly awful when trying to do cross-platform automation of anything that involves building DMD. The make targets are completely different, the available configuration options and defaults are completely different, and the output locations are completely different. Trying to deal with and accommodate the divergent behaviors of posix.mak and win*.mak is a minefield that leads to fragile, tangled code even with my best attempts to keep it clean. And this isn't the first time I've automated building DMD, either.

And yea, all those differences can be addressed, but as long as we're maintaining posix/win buildscripts separately - and in essentially two separate languages (two flavors of make) - then divergence is only going to reoccur.

On 8/10/13 10:48 PM, Walter Bright wrote:
> On 8/10/2013 4:21 PM, Jonathan M Davis wrote:
>> On Saturday, August 10, 2013 14:35:04 Nick Sabalausky wrote:
>>> Is this something that would be acceptable, or does building DMD for
>>> Windows need to stay as DM make?
>>
>> I don't see any problem with it, but that doesn't mean that Walter won't.
>
> Tools built for Unix never work right on Windows. It's why, for example, I run git on Linux and
> don't use the Windows badly ported versions of git. Tiresome problems revolve around failure to
> adapt to \ path separators, ; in PATH, CRLF line endings, Windows SEH, case insensitive file names,
> no symbolic links, etc., no Perl installed, etc.
>
> DMD and Phobos are fairly unusual in how well adapted they are to both Windows and Linux.

Gross over generalization when talking about _one_ app in _one_ scenario.  You're deflecting rather than being willing to discuss a topic that comes up regularly.  You are also well aware of just how often having multiple make files has cause pain by them not being updated in sync.

Does gmake have _any_ of those problems?

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.

On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control. Some issues:

http://d.puremagic.com/issues/show_bug.cgi?id=10710

http://d.puremagic.com/issues/show_bug.cgi?id=8756

Walter Bright:

> On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control. Some issues:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10710
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8756

Issue 8756 doesn't seem caused by libcurl. (If the pragma(lib) feature is not portable then perhaps it should become a feature of just DMD and not of the D language. This aligns a bit better the theory/dream of D with the reality of D.)

On the other hand doing everything yourself/ourselves has some other large disadvantages, look at the Phobos bigints: the GHC Haskell compiler uses the GMP multi-precision numbers, that are usually faster or much faster than Phobos ones, have more functions implemented that are missing in Phobos (like power-modulus), and help GHC developers focus on more Haskell-related issues.

Rust developers don't try to design/develop at the same time a language, a linker, a back-end, a run-time and a standard library. Restricting the work helps speed up the development of what's more related to D.

Bye,
bearophile

On Sunday, 11 August 2013 at 21:21:45 UTC, bearophile wrote:
> Walter Bright:
>
>> On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control. Some issues:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=10710
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=8756
>
> Issue 8756 doesn't seem caused by libcurl. (If the pragma(lib) feature is not portable then perhaps it should become a feature of just DMD and not of the D language. This aligns a bit better the theory/dream of D with the reality of D.)

Does pragma(lib, "curl") not work on Windows/DMD? I know it does in Linux (used in DMD and LDC, ignored under GDC),
and was under the impression that that was the portable way to use pragma(lib).

If it isn't now, I would argue that naming the library (rather than the file) should be the standard, accepted use of pragma(lib). It neatly avoids cluttering D code with version()s and repeated pragmas to handle the different naming schemes.

On 8/11/2013 2:21 PM, bearophile wrote:
> Walter Bright:
>
>> On the subject of friction, I believe we make a mistake by making a dependency
>> on libcurl, a library over which we don't have control. Some issues:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=10710
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=8756
>
> Issue 8756 doesn't seem caused by libcurl. (If the pragma(lib) feature is not
> portable then perhaps it should become a feature of just DMD and not of the D
> language. This aligns a bit better the theory/dream of D with the reality of D.)
>
> On the other hand doing everything yourself/ourselves has some other large
> disadvantages, look at the Phobos bigints: the GHC Haskell compiler uses the GMP
> multi-precision numbers, that are usually faster or much faster than Phobos
> ones, have more functions implemented that are missing in Phobos (like
> power-modulus), and help GHC developers focus on more Haskell-related issues.

You might consider that D is designed to be *very* friendly to linking with existing C code libraries for exactly that reason. Haskell is not. You might also recall my steadfast opposition to doing things like rolling our own crypto libraries rather than linking to existing ones.

That said, as soon as the D *package* starts to depend on non-default-installed libraries, trouble happens. With libcurl, the only solution so far seems to be to BUILD OUR OWN LIBCURL binary!

http://d.puremagic.com/issues/show_bug.cgi?id=10710

This is a terrible situation.

Consider things like the trig functions. D started out by forwarding to the C versions. Unfortunately, the C versions are of spotty, unreliable quality (even today!). Because of that, we've been switching to our own implementations.

And, consider that using GMP means CTFE would not be supported.

> Rust developers don't try to design/develop at the same time a language, a
> linker, a back-end, a run-time and a standard library.

Neither did D's developers. Note that D was developed with existing backends and linkers. Rust is not released yet, and given that they just switched to their own runtime, they clearly intend to ship with their own runtime.

> Restricting the work helps speed up the development of what's more related to D.

We really aren't complete fools, bearophile.

Oh, I forgot to mention, licensing.

We want Phobos to be free of any restrictive licensing. GPL is restrictive, and so is LGPL.

We very deliberately picked Boost. Having Phobos be a mix of GPL and Boost would utterly defeat picking Boost.

On Sunday, August 11, 2013 14:43:13 Walter Bright wrote:
> That said, as soon as the D *package* starts to depend on non-default-installed libraries, trouble happens. With libcurl, the only solution so far seems to be to BUILD OUR OWN LIBCURL binary!

At this point, I'm inclined to think that while it's great for us to have bindings to C libraries and to have user-friendly, D wrappers around them, it's better that they don't end up in Phobos.

- Jonathan M Davis