<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 June 2015 at 09:37, Manu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d<br>
<div><div class="h5"><<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On 1 Jun 2015 07:57, "Manu via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>><br>
> wrote:<br>
>><br>
>> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d<br>
>> <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
>> > On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:<br>
>> >><br>
>> >> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:<br>
>> >>><br>
>> >>> As for dub, I'd use it if it worked like a package manager; dub get<br>
>> >>> libcurl-d libqt-d zlib-d libsdl2-d etc<br>
>> >>> I have no use for it as a build system, and therefore it's expression<br>
>> >>> of dependencies is no use to me. I just want something that works the<br>
>> >>> same way as '-dev' packages already work perfectly well in linux, that<br>
>> >>> is, they fetch headers and libs, and put them in a standard location<br>
>> >>> that all the tooling can find.<br>
>> >><br>
>> >><br>
>> >> I thought it does that.<br>
>> >><br>
>> >> If dub doesn't allow me to type one command to download and install all<br>
>> >> I<br>
>> >> need about a package, we need to add that pronto. I consider it a<br>
>> >> dealbreaker.<br>
>> >><br>
>> >><br>
>> >> Andrei<br>
>> ><br>
>> ><br>
>> > dub fetch does this already (though probably not quite what you are<br>
>> > thinking<br>
>> > of). You'd need to specify the paths manually because if it installed<br>
>> > them<br>
>> > to the global compiler paths we'd have dependency hell (what if 5<br>
>> > projects I<br>
>> > have need 3 different versions of a library?). Also, you'd need root<br>
>> > permissions.<br>
>><br>
>> Yeah, but regardless, that's what I want.<br>
>> I don't have version hell with C libs distributed this way...? Is this<br>
>> a problem that people are specifically trying to avoid?<br>
>><br>
>><br>
>> > That's not really how you use dub though. dub simply isn't a good fit<br>
>> > for<br>
>> > people who want it to be a system package manager. Its goals are<br>
>> > different.<br>
>> > If people want that they should work on getting libraries added to their<br>
>> > preferred system's package registries.<br>
>><br>
>> Right, so, someone decide a path, we'll write it on <a href="http://dlang.org" target="_blank">dlang.org</a>, and<br>
>> then everyone will agree and fall in line :)<br>
>><br>
>><br>
>> > With dub you specify the dependencies in the dub config file, not in<br>
>> > some<br>
>> > obscure section of an INSTALL file as a command the users need to run.<br>
>> > You<br>
>> > can checkout a project using dub and with a single command have dub<br>
>> > download<br>
>> > and build all the dependencies (and their dependencies) and then build<br>
>> > your<br>
>> > project against them.<br>
>><br>
>> I get it, it sounds great... if your app suits the model.<br>
>> I have no D-only projects, all my programs combine many languages and<br>
>> ecosystems.<br>
>> There are also existing build systems that are well established that I<br>
>> prefer to use, integrate with IDE's, etc.<br>
>><br>
>> I don't mind if people use dub, but I just want a way to fetch libs<br>
>> that the compilers will then find automatically.<br>
>><br>
><br>
> Just to be clear, libs are source libraries, right?<br>
<br>
</div></div>Well, it should support libs that aren't JUST source. Binary libs<br>
needs some .d files to declare the API and all that, so at least some<br>
source would always present. A lib on its own us no use :)<br>
But any solution needs to support closed-source libraries too. Not<br>
everything can be conveniently distributed as full-source, and many<br>
libs are bindings against binary C libs which would probably be<br>
sourced externally.<br>
<span class=""><br>
<br>
>> > dub is about making it easy for 99% of users. If you need your own build<br>
>> > system then using dub just to download packages is overkill. Use git<br>
>> > submodules or add something to do a download of your dependencies from<br>
>> > github as part of your custom build system.<br>
>><br>
>> Point is, I don't have to do this with C. I just install the dev<br>
>> package, once, and I'm done. Package manager distributes updates<br>
>> automatically, everything it exactly how I want it.<br>
>> It's just not a wheel I have any interest in reinventing.<br>
>><br>
><br>
> This is a feature of your distribution, and not the language itself.  I'm<br>
> having talks with the Debian toolchain maintainer, we want to start shipping<br>
> D programs and libraries with Debian/Ubuntu.<br>
<br>
</span>Do want! :)<br>
<span class=""><br>
> Binary libraries are going to be the most interesting problem here because<br>
> dmd and ldc will be shut out from using them.<br>
<br>
</span>?<br>
Why is?<br>
<span class=""><br>
> This is a semi call-out to the ldc devs, we should really align our ABIs<br>
> together.<br>
<br>
</span>Oh, are the LDC/GDC ABI's not consistent on linux?<br>
Surely many/most libs are just references to C '-dev' packages as dependencies?<br>
</blockquote></div><br></div><div class="gmail_extra">Our druntimes need to be aligned up.  The first thing you'd notice is that each may give undefined references to things the other compiler does not include in it's runtime.<br></div></div>