std.parallelism is accepted into Phobos

Paulo Pinto pjmlp at progtools.org
Tue Apr 26 11:13:53 PDT 2011


You forgot the new build tool from Microsoft.

Nowadays the official build tool in Windows world, is slowly becoming 
msbuild,
a Microsoft Ant clone, even for C and C++ builds.

--
Paulo


"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:ip70qm$rfq$1 at digitalmars.com...
> 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 




More information about the Digitalmars-d mailing list