On Monday, 22 December 2014 at 18:33:42 UTC, Russel Winder via
On Mon, 2014-12-22 at 12:57 +0000, uri via
Thanks, I'm in the process of looking at CMake/SCons
alternatives right at the moment and will have a look at dco.
May I ask why SCons is insufficient for you?
It isn't. We review our build system every 12 months over Xmas
quite period and tidy it all up. Part of the process is trying
We use Python +SCons to drive our builds and CMake to generate
native makefiles. We find this approach scales better in terms of
speed and system load.
It is a pity CMake invented it's own noisy script though. I also
find with CMake it can be extremely difficult to establish
context when looking at the code. This is why we're slowly
migrating to SCons.
I'm trying dub at the moment and it's working perfectly fine
so far as a build tool. The alternatives, such as CMake and
SCons, are proven technologies with D support that have also
worked for me in the past.
Can I ask what the existing tools were missing and why did you
felt it necessary to reinvented your own build tool?
The makers of Dub chose to invent a new build tool despite
and SCons. Although it is clear Dub is the current de facto
build tool for pure D codes, there is nothing wrong with
experiments. I hope we can have an open technical discussion of
points, it can only help all the build systems with D support.
I really like DUB for quick development, but in it's current form
I don't see it scaling to larger builds. IMO the use of JSON puts
it on par with the Java build tool Ant. JSON and XML (Ant) are
data formats, not scripting languages and In my experience a
large build system requires logic and flow control. I've had to
do this before in Ant XML and it isn't pretty, nor is it flexible.
I use SCons for personal D projects that I think will be long
lived and DUB for quick experiments. I was using CMake for
personal work but that script is too ugly :)