Prototype buildsystem "Drake"

[Chris Molozian]

I completely agree. I definitely believe that work on a new build tool 
is worthwhile especially if it has built in support for D. It's a shame 
that so many build tools at the moment are being developed using 
interpreted languages, it's obviously for the benefits of creating DSLs 
that extend the base language itself. They tend to suffer from slowness 
though (my subjective opinion ;-) ).

I don't think building the tool in D is a good idea either for reasons 
mentioned by Ulrik. It's worth considering using Lua 
<http://www.lua.org/> or Io <http://iolanguage.com/> for the build 
description language but writing the tool in C (or other).

Cheers,

Chris


On 07/13/11 23:32, Ulrik Mikaelsson wrote:
> 2011/7/13 Nick Sabalausky<a at a.a>:
>> "Jacob Carlborg"<doob at me.com>  wrote in message
>> news:ivke5k$2m78$1 at digitalmars.com...
>>> First I have to say that I know you are doing this because you want to use
>>> D as the language for the build scripts. The reason I did choose Ruby
>>> because I think D will be too verbose and when I'm looking at drakefile.d
>>> I do think it's too verbose.
>> Yea, D is likely to be a little more verbose than what could be done in Ruby
>> (or Python). Personally, I think that's well worth it, though. I don't know
>> how many others would agree or not.
>>
> 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)? Seriously, I'm really asking, since
> I'm having a hard time seeing it? Personally, I can only see the
> drawbacks;
>
>   * Building druntime and phobos might be difficult with a d-based buildtool
>   * The build-tool itself will need bootstrapping. A user that wants to
> test some D-project, will first have to aquire (build) and install
> some D-compiler with custom tools. Then install druntime with another
> custom build-system. Then Phobos. Then drake. And THEN, the
> application/library he/she was interested in. Shortening this path is
> IMHO REALLY important to see more D adoption. From my personal
> experience, convincing developers and testers to fight through this
> path is HARD.
>   * Cross-language builds (project with bindings), and builds with
> external targets might be more difficult than need be, if the "2nd"
> language is not supported by drake.
>   * Verbose build-script is IMHO a _really_ undesireable trait.
>   * How soon will I as a developer be able to "just build" a D-binding
> to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
> Gentoo, be able to count on this working in his/her envrironment too?
>   * Non-compilation actions will have to be reimplemented; document
> generation, test execution, install-tasks following OS-specific
> install procedures (XDG-guidelines etc.), ...
>
> IMHO, it sounds like a case of the NIH-syndrome, but I might be
> missing something obvious?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110713/329d948f/attachment.html>