Prototype buildsystem "Drake"

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jul 15 09:13:08 PDT 2011


On 7/14/11 3:00 PM, Jacob Carlborg wrote:
> On 2011-07-14 04:37, Andrei Alexandrescu wrote:
>> On 7/13/11 5:32 PM, Ulrik Mikaelsson wrote:
>>> Not trying to be argumentative, but what exactly do you see as the
>>> gains in having a D-buildtool built in D (or D-specific build-tool in
>>> any language, for that matter)?
>>
>> I think it's a matter of positioning D and eating one's dogfood. If D is
>> inconceivable for the kind of tasks that Python or Ruby are adept at,
>> then sure, we could and should use either. On the other hand, if we
>> advocate D as a good tool for short scripts, using the competition would
>> hurt its brand.
>>
>> Personally I believe D is plenty adequate for short scripts, of which
>> I've written a ton of. So the path of least resistance for a package
>> manager or for a build tool is D, not any other language. I'd question
>> much harder the decision of using another language (D is, however, not a
>> competitor for the likes of bash or make).
>
> Isn't it a competitor for make in this case?

What I meant here is that it's reasonable for a build tool for D to 
require make without impacting its brand.

>> I see no NIH here. D is an ample language scaling up to large programs
>> and down to scripts. If the question is to build a tool from scratch, D
>> is the obvious choice and any other choice is just odd. It's like some
>> tools I've seen (none successful) that required the competition's
>> product to be installed in order to work.
>>
>>
>> Andrei
>
> I though we were talking about what language the build scripts should
> use, not the language the actual build tool should be written in. I
> think these are two separate issues and all tools mentioned (Drake,
> Orbit, Dake) in this thread are implemented in D.
>
> My tools, using Ruby as the scripting language, have Ruby embedded in
> the tool and requires no installation of Ruby.

I believe use of Ruby for scripting is a strategic mistake for a small 
benefit. The users your tools should not need to learn any amount of 
Ruby (or Scala for that matter) in order to build D programs. What we 
need is, if necessary, to improve D to better address the needs for 
scripting a build tool. That way your work would be pushing D's state of 
the art in addition to adding value on its own. I suggest you reconsider.


Thanks,

Andrei


More information about the Digitalmars-d mailing list