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).
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
Druntime and phobos are distributed, and only built by a small number of users. We should not worry about building them. Also, a tool based on other language would require that language's environment to be already available.
* 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.
The installation provides the adequate tools. Installing and building from scratch is unnecessary. A user wanting to test some project needs to (a) install dmd using OS-specific installation tools (which we already have) and (b) use the provided tools to build whatever project.
* 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.
This is a good advantage of generic build tools.
* Verbose build-script is IMHO a _really_ undesireable trait.
I don't understand this.
* 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?
This pretty much depends on the capabilities of the tool, which would have to be fairly D-specific.
* Non-compilation actions will have to be reimplemented; document generation, test execution, install-tasks following OS-specific install procedures (XDG-guidelines etc.), ...
Here you're conflating the capabilities of the tool with the capabilities of the _langauge_ used to implement the tool.
IMHO, it sounds like a case of the NIH-syndrome, but I might be missing something obvious?
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
