Am 01.06.2015 um 09:19 schrieb Iain Buclaw via Digitalmars-d:
On 1 Jun 2015 09:09, "Manu via Digitalmars-d" <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: > > On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d > <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: > > > > On 1 Jun 2015 08:45, "Nick Sabalausky via Digitalmars-d" > > <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: > >> > >> On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote: > >>> > >>> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d > >>>> > >>>> 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 <http://dlang.org>, and > >>> then everyone will agree and fall in line :) > >>> > >> > >> Not sure how serious/joking you are about that, but when has declaring a > >> standard whatever like that ever worked for anything ever? ;) Linux can't > >> even agree with Linux on where things should go, apparently that's why C on > >> linux has pkg-config. > >> > > > > Leave it to the distribution is the safe option in my experience. To have > > something along the lines of what Manu wants, I guess we need something like > > virtualenv to allow building in a clean/standard environment. > > Yeah, I think I can see 2 parallel problems here. > 1. There is a lib installed from a -dev package managed by the > distribution... I just want the complementary .d files. (this is what > I actually care about) > 2. There is some open-source D code which isn't distributed as a > binary, it's just a git repo and you fetch it and build it locally. (I > find that I rarely need this, so I don't have much opinion on this > case) > > For case 1, my preference would be a distro managed package alongside > the lib itself, and installed into a standard location. If dub could > pull the bindings I want and put them in some common location, fine. > For case 2... I dunno. What if you offer a lib that falls into case 2; > source is available, user can fetch and build against it locally, but > it contains C code too? dub isn't exactly a build system which can > express a complex build environment. > I can't create a dub package for my engine, which might be of interest > to D gamedevs. In one sense this can be solved at the distribution level. If dub was provided through your package manager, the package maintainers can ensure that dub was configured to understand where all system sources are located (or will be located). Can all of dubs default settings be dumped to json and be overriden?
It would be possible to put a ".dub/settings.json" with custom settings into the distribution package (hmm, /etc/dub/settings.json or similar should probably supported in addition to that...).
