std.parallelism is accepted into Phobos

[Andrei Alexandrescu]

On 4/26/11 11:56 AM, Russel Winder wrote:
> 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.

This has been a common complaint about make... until gmake came about. 
Targeting gmake newer than a specific version seldom causes 
platform-related issues.

>> :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.

It is a great metric because they are in a ratio determined by the tools 
used. 312 lines to build 143K lines seems a good ratio to me - probably 
some of the best I've seen.

The 312 lines make is only for Phobos. If you could reduce and simplify 
it, we'd all appreciate it.

>> 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.

Sorry, you are wrong here. Please take a look!

>> 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.

Exactly!

> 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.

The general considerations are most appreciated. I don't think scare of 
change is an issue for us.

> 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. :-(

What also matters is that stuff that stays is stuff that gets done. You 
seem to have a good amount of expertise, but at the same time choose to 
firmly plant your figurative self in the proverbial armchair. If you 
know how to do it, do it, don't attempt to beat others into doing it.


Andrei