Make dub part of the standard dmd distribution

[Manu via Digitalmars-d]

On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 1 Jun 2015 07:57, "Manu via Digitalmars-d" <digitalmars-d at puremagic.com>
> 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.
>>
>
> Just to be clear, libs are source libraries, right?

Well, it should support libs that aren't JUST source. Binary libs
needs some .d files to declare the API and all that, so at least some
source would always present. A lib on its own us no use :)
But any solution needs to support closed-source libraries too. Not
everything can be conveniently distributed as full-source, and many
libs are bindings against binary C libs which would probably be
sourced externally.


>> > 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.
>>
>
> This is a feature of your distribution, and not the language itself.  I'm
> having talks with the Debian toolchain maintainer, we want to start shipping
> D programs and libraries with Debian/Ubuntu.

Do want! :)

> Binary libraries are going to be the most interesting problem here because
> dmd and ldc will be shut out from using them.

?
Why is?

> This is a semi call-out to the ldc devs, we should really align our ABIs
> together.

Oh, are the LDC/GDC ABI's not consistent on linux?
Surely many/most libs are just references to C '-dev' packages as dependencies?