Thread overview
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
Aug 13, 2013
H. S. Teoh
Aug 13, 2013
Walter Bright
Aug 13, 2013
Nick Sabalausky
August 13, 2013
On Mon, Aug 12, 2013 at 04:18:12PM -0700, Walter Bright wrote:
> On 8/12/2013 3:48 PM, H. S. Teoh wrote:
> >Objectively speaking, though, this is no different from being required to install make in order to compile dmd. You still have to go out of the way to install a 3rd party program before you can build dmd. The only difference is that make tends to be preinstalled in more systems than python (though nowadays most Linux distros come with python by default, so this factor is becoming much less out of place than you're suggesting).
> 
> 1. Python is not preinstalled on Windows. So then the question is, which Python should the user install? What happens if the user doesn't like that version? What if it conflicts with his other Python he's got installed? What if the Python version is different? What if Python releases an upgrade, and our build system needs to be adjusted to account for that?
> 
> 2. Make comes with g++. g++ is used to build dmd, so if g++ is installed, so is make.
> 
> 3. Make doesn't come preinstalled on Windows. But we have a make we can throw in the bin directory without issues. It's only 50K. Nobody goes out of their way - it's there on the same path as dmd. It's always the right version of make to use with our makefiles. We're not going to get into the Python distribution business.

But if we bundle a D-based build tool in the bin directory...


> 4. Having Python as a prerequisite for using D just paints the wrong image for D.

That I agree with. :)


> 5. Do we really want D to be restricted to only platforms that have the latest Python up on them?

I think that's a bit of hyperbole. It's the same as saying "do we want D to be restricted to only platforms that have g++/make installed?"

This is where a D-based build tool comes in. We ship the prebuilt build tool, then that can be used to build dmd (which can in turn be used to build newer versions of the build tool). That way we are freed from dependence on anything else, esp. once dmd is fully ported over to D.


> So no, I do NOT at all regard the issue of requiring Python to be remotely equivalent to requiring Make.
> 
> We did have a problem on FreeBSD because the default make on it would not work with posix.mak. gmake had to be explicitly installed. The only saving grace there is that very few people use FreeBSD, and those that do, tend to be pretty handy with installing gmake.

This is the plague of makefiles. They *almost* always work, but when they don't, it's a mess.

If we have a D build tool that we ship with the dmd sources, then we will have (1) a superior build system to make, (2) no external dependence on gmake / python / whatever else. Since we're aiming for dmd to be itself written in D, we might as well just self-host the build system too. And this tool can be used to build other D programs in general, not just dmd / druntime / phobos.


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are gone to milk the bull. -- Sam. Johnson
August 13, 2013
On 8/12/2013 5:19 PM, H. S. Teoh wrote:
>> 5. Do we really want D to be restricted to only platforms that have
>> the latest Python up on them?
>
> I think that's a bit of hyperbole. It's the same as saying "do we want D
> to be restricted to only platforms that have g++/make installed?"

No, I don't think it's hyperbole. I would bet that a C++ compiler (which invariably come with a make) exists on essentially every platform 32 bits or larger. Python? Doesn't seem likely.


> If we have a D build tool that we ship with the dmd sources, then we
> will have (1) a superior build system to make, (2) no external
> dependence on gmake / python / whatever else. Since we're aiming for dmd
> to be itself written in D, we might as well just self-host the build
> system too. And this tool can be used to build other D programs in
> general, not just dmd / druntime / phobos.

I think you're underestimating the amount of effort needed to build a "proper" build tool, even to get it up to the level of make. For example, gmake has the -j switch, enabling building using all the cores on your CPU. This is a big deal, but I don't think it's so easy to create a bug-free implementation of it.

(DM make does not have -j.)

August 13, 2013
On Mon, 12 Aug 2013 17:44:35 -0700
Walter Bright <newshound2@digitalmars.com> wrote:

> On 8/12/2013 5:19 PM, H. S. Teoh wrote:
> >> 5. Do we really want D to be restricted to only platforms that have the latest Python up on them?
> >
> > I think that's a bit of hyperbole. It's the same as saying "do we want D to be restricted to only platforms that have g++/make installed?"
> 
> No, I don't think it's hyperbole. I would bet that a C++ compiler (which invariably come with a make) exists on essentially every platform 32 bits or larger. Python? Doesn't seem likely.
> 

Yea, while python is indeed hugely widespread, it still doesn't compete with C++/make in availability. There are people who deliberately avoid having scripting packages like python on certain systems for various legitimate reasons.

Plus (and this is one of my primary beefs with Python), tools written in Python often have a tendency to expect a certain version of Python (or even certain lib dependencies), and it's up to the person *running* the program to make sure the script is given the right installation of Python. Woe is the user who gets it wrong, because they'll just be greeted with a big internal traceback. It's not like Java where you can install whatever runtimes you need and things will pretty much just run themselves on the correct version automatically, or tell you what expected version you're missing.

(Not that I'm advocating make, either)