On 2013-08-13 19:37, Nick Sabalausky wrote:

> Sort of, but...no, not really.
>
> Since this tool would be cable of generating any platform-specific
> makefile or script or whatever, and there's no reason to restrict it
> to *only* generate a makefile/script for the current platform, that
> means it can function much like a cross-compiler:

Well if you output a build file for a different tool that's completely different.

-- 
/Jacob Carlborg

On Tue, 13 Aug 2013 15:13:38 +0200
"Kagamin" <spam@here.lot> wrote:

> On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote:
> > Would it be
> > acceptable to use gmake as *the* make for DMD? Ie, either
> > convert the
> > windows makefiles to gmake, or expand the posix makefiles to
> > support
> > windows?
> 
> 1. expand posix makefiles to support windows
> 2. leave dm makefile for those who doesn't have gmake
> 3. use unified posix/windows makefile
> 4. everyone is happy

That still involves the overhead of maintaining duplicate makefiles and a tendency for gradual divergence.

On 8/13/13 10:39 AM, Jacob Carlborg wrote:
> On 2013-08-13 19:37, Nick Sabalausky wrote:
>
>> Sort of, but...no, not really.
>>
>> Since this tool would be cable of generating any platform-specific
>> makefile or script or whatever, and there's no reason to restrict it
>> to *only* generate a makefile/script for the current platform, that
>> means it can function much like a cross-compiler:
>
> Well if you output a build file for a different tool that's completely
> different.

And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem.

The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling.


Andrei

On Tue, Aug 13, 2013 at 01:45:41PM -0400, Nick Sabalausky wrote:
> On Tue, 13 Aug 2013 15:13:38 +0200
> "Kagamin" <spam@here.lot> wrote:
> 
> > On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote:
> > > Would it be acceptable to use gmake as *the* make for DMD? Ie, either convert the windows makefiles to gmake, or expand the posix makefiles to support windows?
> > 
> > 1. expand posix makefiles to support windows
> > 2. leave dm makefile for those who doesn't have gmake
> > 3. use unified posix/windows makefile
> > 4. everyone is happy
> 
> That still involves the overhead of maintaining duplicate makefiles and a tendency for gradual divergence.

It violates DRY, and thus inherits all of the associated problems.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.

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.

On 8/13/2013 10:14 AM, Nick Sabalausky wrote:
> I think he's referring to technical issues with gmake apparently not
> always playing nice on windows.


There's only one post by Brad in this thread and one reply! What's the mystery?

On Tue, 13 Aug 2013 10:50:28 -0700
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 8/13/13 10:39 AM, Jacob Carlborg wrote:
> >
> > Well if you output a build file for a different tool that's completely different.
> 
> And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem.
> 
> The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling.
> 

I think it's more telling of the fact that programmers tend not to
agree on things ;)  (...Not entirely joking, either.)

On 8/13/2013 3:54 AM, Russel Winder wrote:
> (**) Anyone using Python earlier than 2.7 is either contractually
> obliged or nuts. Most sensible folk are already using Python 3.3 or
> rapidly moving towards it.  SCons sadly is not Python 3 compatible. At
> least not yet, but there are plans.

So SCons is developed by people who are nuts? :-)

On Tue, 13 Aug 2013 14:17:55 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Tue, 13 Aug 2013 10:50:28 -0700
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
> > On 8/13/13 10:39 AM, Jacob Carlborg wrote:
> > >
> > > Well if you output a build file for a different tool that's completely different.
> > 
> > And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem.
> > 
> > The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling.
> > 
> 
> I think it's more telling of the fact that programmers tend not to
> agree on things ;)  (...Not entirely joking, either.)
> 

But more seriously though, I think a fairly clear solution *has* emerged: A D-based tool. Everything else, including maintaining the status quo, has pretty much been ruled out by the majority for one reason or another - or at the very least have all has serious objections raised. But there haven't been any serious objections to the idea of a D-based tool - just some productive discussion of what form it should take.

Besides, a solution doesn't need to be "a slam-dunk" to be worthwhile.

Well, there has been announcement of D-based build system (bub) recently, maybe it can be used for some dogfooding? :)