Am 12.12.2013 17:15, schrieb Dicebot:

On Thu, 12 Dec 2013 16:01:45 +0100, Sönke Ludwig wrote:

I don't know, they are coupled in may ways, but most importantly
facilitating using different build systems is probably the last thing I
would support, or put differently, the converse was one of the prime
reasons for even starting DUB. It's a tremendous advantage for the
ecosystem to have a unified build system, where things "just build"
without having to install different build tools or having to adjust make
scripts because they don't work on a certain platform etc.

If that is the case then choice of project definition format is rather horrible (in context of build system). It needs to be at least close in power to makefiles to be viable in that role. I have tried to convert internal sociomantic projects to dub some time ago (with locally hosted own registry) to address some dependency tracking issues we have and was displeased with results to the point of abandoning the idea. It just does not scale even for projects of medium complexity.

What exactly were the issues where it doesn't scale?

Remember that the build system is still in its infancy and hasn't
received much work. But everything else should work fine in projects of
any size.

I'd really love to see something like https://github.com/GrahamStJack/bottom-up-build used instead as standard system. Possibly with changes to allow stuff like dub describe but I am pretty sure it is possible.

The problem is that the more generalized you make the system the more
specialized will the "build descriptions" become - like Heisenberg's
uncertainty principle ;). At some point you lose the "just works" and
have to adjust everything for every dependency and every
platform/whatever. Also you'll frequently discover packages which don't
support this or that kind of build (debug build, or building as shared
library, or 64-bit). My goal is to find a sweet spot that fits and has
advantages for >90% of the projects, but still allows to handle the rest
of the projects one way or another.

If a project has a structure that doesn't really fit, on one hand you
could argue that it likely could be simplified by splitting it up into
smaller units. On the other hand you can also always do things like
making a wrapper DUB package that just defines import paths and import
libraries, but invokes "make" or another build system from the pre-build
or pre-generate commands to actually build the package.