On 03/17/2016 06:42 PM, Piotrek wrote: > On Thursday, 17 March 2016 at 15:49:07 UTC, Dicebot wrote: >> On 03/17/2016 07:15 AM, Piotrek wrote: >>> As for dub I don't think it is unrelated. Why std.build couldn't be >>> dependency manager? >> >> For same reason you don't want to distribute any other non-trivial >> tools as sources :) Compilation takes time and has non-trivial >> dependencies (i.e. networking libraries, git providers etc.), you >> simply can't put that stuff as a stdlib module/package and expect >> developers to compile it each time. > > Hmm, the build module could be compiled once. It sources are supposed to > stay unchanged, right?
Even "once" will be too much for majority of D users (those who are not also Gentoo users at least :D). Remember - we are not speaking about build as simple as `rdmd std/build.d` at this point, it will have numerous additional dependencies, including linker dependencies. And has to be perfectly cross-platform. >> Tight coupling of dependency management and build tool in one entity >> is just too inflexible. This is single biggest issue I have with dub >> in its current form. > > Can you explain it by example (I don't mean dub problems, which I agree > exist, but the inflexibility in general)? > I can't see a conflict between the two functionalities. Typical example - we use custom Makefile based framework for internal Sociomantic D projects, one which is much more capable than existing dub build support and works decently for our needs overall. There is no way it can be replaced with dub at its current state. However using the very same dub to fetch sources of 3d-party libraries and ensure version compatibility is something quite desired. When build tool and package management system are packed into one tool, you pretty much need for both to be perfect to match everyones desires. And that is simply impossible.