On Sat, 2017-06-17 at 12:20 -0700, Walter Bright via Digitalmars-d
> It's highly unlikely it would be accepted:

So it is highly unlikely I am going to offer to do any work on it then.

I am extremely disappointed in the attitude displayed by your reply, it
shows a lack of interest in doing things better. This is ironic in the
extreme given it is the build infrastructure for a compiler for
programming language supposedly to help make things better for

> 1. make is ubiquitous. It's not something we have to scrounge to find
> on 
> platform X, it's already there. People already are familiar with it
> (even if 
> they hate it).

"is ubiquitous" is a lazy answer. Python is ubiquitous to the same
extent. Of course you still have to install make so actually it isn't
as ubiquitous as the comment implies.

> 2. we're in the D business, not the project build business. It's
> easier to get 
> past that "first 5 minutes" if everything about D other than D itself
> is 
> familiar and conventional.

You may be in the D business and already know the Make-based framework
intimately, but it is a barrier to anyone else wanting to contribute.
The inference must thus be that you don't want new contributors to the
compiler. That's fine, but a dead end for the future of D.

> 3. to steal from Churchill, `make` is the worst form of build system
> except for 
> all the others

Argumentation by false analogy.

> 4. much as I dislike make, the time spent wrestling with it is a
> vanishingly 
> tiny slice of time compared to what spent on the rest of D. Getting
> that time 
> slice to zero will have no effect on productivity, and I'm not
> convinced that a 
> newer build system will even reduce that time slice at all (see point
> 5).

As you have no experience you have no data point. Everyone else, who
does have actual data is moaning like crazy about staying with a pure
Make/Shell system.

The world has moved forward in build in the last 40 years, can I
suggest you try and learn a little bit about it.

> 5. D has a more complex build process than it should. Using another
> build system 
> won't make that complexity go away.

Yes it will.

> 6. unlike the choice to use github, there is no clear winner in the
> `make` 
> category of build tools. If the industry has moved on from make to X,
> then we 
> should, too. But it has not.

Yes it has. I suspect you are focussing too much on the D compiler
internals and not enough on the programmer development environment and
tools progress that has been made in the last 20 years.

> 7. the current makefiles for DMD suffer from over-engineering, i.e.
> making 
> simple things complicated and excessively using obscure features of
> make. This 
> isn't really the fault of make.

Again faulty reasoning. Replacing a system is a way of getting rid of
crap and getting something better.

I am not a fan of fashion or fadism in software development, but
neither am I a fan of ignoring all progress so as pretend nothing has
changed. There is nothing wrong with a project changing its build
system on a regular, although not too frequent, basis.

D should be there at the cutting edge of software development in its
own environment as an integral part of the pitch to the developers.
Rust and Go have done this – well Go has a problem with vendoring, but
like most of the Go community, we'll pretend it isn't a big problem.

Reggae is D's pitch in the CMake and Meson class of meta-build tools.
Why aren't all the D compiler and tool developments using it? Or if
Reggae is a step too far because it is a D program offering D (or
Python, Lua,…) specifications of build, use Meson.

Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to