std.parallelism is accepted into Phobos

[Russel Winder]

On Tue, 2011-04-26 at 10:09 -0500, Andrei Alexandrescu wrote:
> On 4/26/11 7:50 AM, Russel Winder wrote:
> > On Tue, 2011-04-26 at 08:32 -0400, dsimcha wrote:
> > [ . . . ]
> >
> >> Soon.  I'm praying that I can figure out makefiles in that time to check
> >> std.parallelism in, since I think they're harder to work with than
> >> multithreading.  (Ok, I'm exaggerating.)  Among the other major
> >> improvements in this release:
> >
> > Isn't Make 1970s technology, I'd have thought D would use more
> > up-to-date build technology than that -- even though Go uses it and
> > refuses to look at other options.
> 
> The debate about make being inadequate is almost as old as make itself 

Hardly.  In 1978 Make was a revelation and a revolution.  Well at least
on Unix.  And that is the problem, Make is all very well if you are on
Unix and can rely on /bin/sh and various other tools.  As soon as you
try to create platform independent builds, Make fails to be sensible
except for trivial builds.

> :o). Our gnu makefile for Posix isn't in any way difficult or scary, 
> although it did take a few iterations to get it right. It has 312 lines 
> to control a build of 143KLOC, which is a good ratio. The only

If the build for DMD and Phobos is a single Makefile of 312 lines then
it almost certainly needs refactoring.  Ratio of source code lines to
Makefile lines is almost certainly a spurious metric.

> difficulty David would have to modify that makefile is to find the one 
> place where all modules are enumerated, and insert his module's name 
> there, so I have no idea why he finds that task daunting. (The Windows 
> makefile is crappier and repeats itself a lot of times so that's more 
> annoying to deal with.)

Why is there a separate Windows Makefile?  Oh of course you actually
have to have separate build systems for Windows, Mac OS X, Linux,
Solaris, etc., etc. because Make is not a platform independent system,
it relies on /bin/sh and other tools. 

> The simple fact is that if someone wants to improve our build system 
> they'd have to define it and argue successfully for its superiority. The 
> issues I'm seeing as a build-systems-outsider who doesn't pay much 
> attention are: (a) there are TONS of them; (b) each has issues that 
> prevents it from becoming a new de facto standard; (c) the "best" one 
> depends a lot on who you ask.

Wrong approach I think.  If anyone cares enough then they write a Waf,
SCons or CMake (or whatever marginal build system people can find) build
in parallel to the Make one using a fork of the D project source.  They
then announce it.  Then people use it.  Then the Make system dies off.

Make has issues that stops it being a modern build system, but it hangs
on because people are scared of change and so do anything and everything
to stay with using it even though it is an outdated system and there are
now far superior ones.

There are indeed zillions of build frameworks.  Every new programming
language ends up having someone write a new build system in it -- Go
appears to have created a record by having about six all written in the
last year.  It is a knee-jerk reaction.  What is relevant is what are
the de facto standards as opposed to de jure standards.  Make and
Autotools are still there because they have been there for 30 years.
Waf, SCons, CMake and Rake are the only tools with traction off the JVM.
Gradle, Maven, Gant, Ant, are the market leaders on the JVM with SBT and
Leiningen have some cult following.  Any other build framework is
currently marginal -- no matter how good it actually is.

There are metrics to decide which is best for a given project.  Fashion
and prejudice do also, sadly, take their place in most projects
decisions. :-(

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110426/1a1cc0ed/attachment.pgp>