Make dub part of the standard dmd distribution

[Rikki Cattermole via Digitalmars-d]

On 1/06/2015 5:57 p.m., Manu via Digitalmars-d wrote:
> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
>>>
>>> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>>>>
>>>> As for dub, I'd use it if it worked like a package manager; dub get
>>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>>> I have no use for it as a build system, and therefore it's expression
>>>> of dependencies is no use to me. I just want something that works the
>>>> same way as '-dev' packages already work perfectly well in linux, that
>>>> is, they fetch headers and libs, and put them in a standard location
>>>> that all the tooling can find.
>>>
>>>
>>> I thought it does that.
>>>
>>> If dub doesn't allow me to type one command to download and install all I
>>> need about a package, we need to add that pronto. I consider it a
>>> dealbreaker.
>>>
>>>
>>> Andrei
>>
>>
>> dub fetch does this already (though probably not quite what you are thinking
>> of). You'd need to specify the paths manually because if it installed them
>> to the global compiler paths we'd have dependency hell (what if 5 projects I
>> have need 3 different versions of a library?). Also, you'd need root
>> permissions.
>
> Yeah, but regardless, that's what I want.
> I don't have version hell with C libs distributed this way...? Is this
> a problem that people are specifically trying to avoid?
>
>
>> That's not really how you use dub though. dub simply isn't a good fit for
>> people who want it to be a system package manager. Its goals are different.
>> If people want that they should work on getting libraries added to their
>> preferred system's package registries.
>
> Right, so, someone decide a path, we'll write it on dlang.org, and
> then everyone will agree and fall in line :)
>
>
>> With dub you specify the dependencies in the dub config file, not in some
>> obscure section of an INSTALL file as a command the users need to run. You
>> can checkout a project using dub and with a single command have dub download
>> and build all the dependencies (and their dependencies) and then build your
>> project against them.
>
> I get it, it sounds great... if your app suits the model.
> I have no D-only projects, all my programs combine many languages and
> ecosystems.
> There are also existing build systems that are well established that I
> prefer to use, integrate with IDE's, etc.
>
> I don't mind if people use dub, but I just want a way to fetch libs
> that the compilers will then find automatically.
>
>
>> dub is about making it easy for 99% of users. If you need your own build
>> system then using dub just to download packages is overkill. Use git
>> submodules or add something to do a download of your dependencies from
>> github as part of your custom build system.
>
> Point is, I don't have to do this with C. I just install the dev
> package, once, and I'm done. Package manager distributes updates
> automatically, everything it exactly how I want it.
> It's just not a wheel I have any interest in reinventing.
>
> I'm not trying to heckle. I just want someone to declare the word on
> where in the filesystem we put .d files, parallel to c includes.
> I think the single most important thing is for bindings against C libs
> that are installed by common -dev packages, it would be easiest if the
> bindings were fetched and installed the same way as the libs they
> refer to.
>

Perhaps a new dub command (--locate)?

$ dub build <package> --version=<version> --arch=<arch> 
--compiler=<compiler> --locate
Base: ~/.dub/<package>-<version>/
Binary: ~/.dub/<package>-<version>/output.lib
ImportPath: ~/.dub/<package>-<version>/source
Pass

Well you get the general gist. Fetches and builds if necessary for 
specific arch ext.
Really it just minimizes output and only output location info.