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. > 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.
