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.
4. Having Python as a prerequisite for using D just paints the wrong image for
D.
5. Do we really want D to be restricted to only platforms that have the latest
Python up on them?
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.
