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@a.a>:
"Jacob Carlborg"<d...@me.com> wrote in message
news:ivke5k$2m78$1...@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?
