Am 16.02.2013 23:58, schrieb Rob T: > > I'm having good success using D itself as the build tool language, and > I'm at the point now where I'm getting much better results than what I > was getting out of using external build tools, so for me there's no > looking back. > > I run rdmd on a .d "script" that I wrote that's setup to do exactly what > I want.
I did that, too, for automated and Linux builds. But this means that if you also want to work with an IDE for debugging and such things, you have to keep additional project files in sync. The DUB approach just combines the two (+ the package management) and also has less overhead than doing it with D (main function, imports, possibly distributing helper modules etc.). > > What is missing from D is a good library of functions that are generally > useful for writing build scripts. Phobos already supplies a great deal > of what is needed that can be used to construct what is missing. > > The benefit of using D is that I do not have to install and learn a > secondary language or conform to a specific build format, or follow any > weird restrictions. What I want to do is build my D code, not learn > something new and perform acrobatics to get the job done. I can even use > the same D process to build C/C++ code if I wanted to expand on it. > But you will have to learn the API of the build script helpers, too. I'm not sure if this is actually less to learn than the JSON alternative. > What I'm saying here is that I see no reason to use a language other > than D itself as the build tool. What D can use is an addition to Phobos > that supplies the necessary generalized functions that all build tools > should supply, and I don't think there's all that much that's missing. > > For a package manager, some standards may be required, but it too can be > done completely with D. Well, DUB is fully written in D, so the question is less D or not, but more if an additional intermediate layer for the package description makes sense or not. > > Why use json (which is a subset of javascript), or ruby, or python, etc? > Is there something fundamentally wrong with D that makes it unsuitable > for this role? > I see the following points for the decision for data/JSON vs. D: - Meta information needs to be available to the package registry and for managing dependencies in general. Executing a script/program would imply a big performance risk, and worse, is a high security risk in case of the registry. So a data-driven approach is needed at least for the meta data anyway. - JSON is a nice standard format with generally low risk of errors. I agree that it is not the prettiest language in the world (although IMHO much better than something XML based). Generally the same recent discussion on the beta list for the dmd.conf format applies here, I'm not sure what is the best approach, but JSON at least is not too bad. To me the most interesting open question is this: Do we actually gain from programmatic support for the build description, or does it suffice to have a good purely descriptive system? If the former should be true for more than 1% of the cases, that would definitely be a good argument against pure data.
