On 1 June 2015 at 17:09, Iain Buclaw via Digitalmars-d
Well, it should support libs that aren't JUST source. Binary libs<digitalmars-d@puremagic.com> wrote:
>
> On 1 Jun 2015 07:57, "Manu via Digitalmars-d" <digitalmars-d@puremagic.com>
> wrote:
>>
>> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d
>> <digitalmars-d@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?
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?