D Development Process

Question

What is the recommended development process for D programs that use packages that are cloned from github and separately built?

Typically in relation to how C/C++ projects are built using make, autotools, cmake, etc.

Most other build specifications have an install target. Should there be an install target in the build or should we just link a library directly from where it is placed when built and add register its includes in D_INCLUDE_PATH and then direct to them using DFLAGS=-I<D_INCLUDE_PATH>?

Boykin

+1 for the question. Some time ago I was looking for this too and couldn't find anything. Ended up using CMake for my own projects and manually installing libraries to personal root like ~/droot (so the libraries were in ~/droot/lib) and specifying this path in CMake configuration. This is far from comfortability of e.g. Java with its Maven or Go with its go get. – Contradict

Has anyone tried Shake with D? community.haskell.org/~ndm/shake – Greenbrier

Answer 1

I realise my comment can actually be an answer to the question, so here it is:

D development process can't be different than similar in C or C++ world. Is that really difficult to see? Almost all C and C++ compilers generate "native" code. D is not an exception. There was the D.NET project that could target .NET, but it is inactive for years...

Furthermore, all tools used in C/C++ based projects can be easily used for anything else. CMake can be used in Java or .NET projects as well. Same goes for Make and/or Autotools. Why are Maven and Ant more popular in Java world is a different story.

Speaking about them, you can use Maven or Ant in the D development process! Hands down, you need to write your own Maven plugins to make it more easy and flexible, but it is doable, and would in fact be a very nice project.

From what I have seen, D programmers stick to the good, old Make, or write BASH script to do the whole thing. However, I've seen people from the Lycus foundation use WAF. If you are Python programmer, you will just LOVE WAF. If not, try similar things - I've seen people use SCons, Remake, Premake, etc...

DSSS+Rebuild is the closest thing to a very useful such tool made with D. Unfortunately they are dead projects. :(

I am working on a maven-style tool, but considering the amount of time I have - it will be usable in 2014. :)

Aridatha

Actually, D building process is very different from C\C++. C\C++ uses header files, and you only need to recompile an implementation file if it is changed, if one of the header files it includes changed, if one of the header files included in headers file included by that file and so on. If you make a change in an implementation file, you only need to recompile that file. D is different - API and implementation are in the same file, and D heavily relies on template metaprogramming so if you change something you have to recompile everything. This makes incremental builds impossible. – Intact

@IdanArye: Good comment. This is the main reason for me asking. Traditional build tools are a lot about manually specifying dependencies. This is not always true for the D build process. For example when using DMD you can generate D interface files (.di) to speed things up but you don't to have to. – Remembrance

I agree with Idan, but I did not want to go into such details. After all the question was not about those, but about the overall lifecycle if I am not mistaken. :) – Aridatha

Answer 2

I would go with scons, which has support for D, thanks to Russel Winder:

http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2959039

If not, then POM (plain old make).

Pulliam