On 1/06/2015 5:57 p.m., Manu via Digitalmars-d 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.
>
>
>> 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.
>

Perhaps a new dub command (--locate)?

$ dub build <package> --version=<version> --arch=<arch> --compiler=<compiler> --locate
Base: ~/.dub/<package>-<version>/
Binary: ~/.dub/<package>-<version>/output.lib
ImportPath: ~/.dub/<package>-<version>/source
Pass

Well you get the general gist. Fetches and builds if necessary for specific arch ext.
Really it just minimizes output and only output location info.

On 05/31/2015 11: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.
>

Ditto. Dub's great if you let it be your buildsystem, but as soon as you want to use it as a package-manager-only it becomes an uphill battle with dub fighting back every step of the way (I speak from experience). That problem is worse if your project is a library that you want fetchable through dub.

That's why I've been working on some PRs to fix all that. The first step is here (building/expanding on a flag another contributer recently added):

https://github.com/D-Programming-Language/dub/pull/572

(Although I think I may need to change --data=libs and separate system libs from dependency libs since linkers expect those to be passed in differently.)

The next step will be to add a flag to have that data get output in a compiler-ready argument list (your choice of compiler, of course). That'll let you do something comparable to "pkg-config --cflags --libs".

Then finally, a shortcut flag so you can just do something kinda like:

rdmd --build-only `dub describe --cmdargs=rdmd` src/main.d

And all your dependencies will be properly referenced (-I..., linker flags, etc).

On 06/01/2015 01:21 AM, Andrei Alexandrescu wrote:
>
> I installed a Python program the other day. I think it's rather obscure
> - it's called "lcinvestor". I got from knowing nothing about how to
> install Python stuff to having the application running in minutes.
>

That doesn't even remotely match my experience trying to use/install python-based software/libs:

https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote:
> Let's make this part of 2.068:
>
> https://issues.dlang.org/show_bug.cgi?id=14636
>
> It's preapproved. Who would want to work on it?
>

IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not certain exactly what work he had in mind for that though, versus post-1.0.

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

On 1 Jun 2015 08:45, "Nick Sabalausky via Digitalmars-d" < 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, 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.

On Monday, 1 June 2015 at 06:35:38 UTC, Nick Sabalausky wrote:
> On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote:
>> Let's make this part of 2.068:
>>
>> https://issues.dlang.org/show_bug.cgi?id=14636
>>
>> It's preapproved. Who would want to work on it?
>>
>
> IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not certain exactly what work he had in mind for that though, versus post-1.0.

DUB has worked equally well and almost unchanged for me in 2015.

On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1 Jun 2015 08:45, "Nick Sabalausky via Digitalmars-d" <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, 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.

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?

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

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

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

On 1 Jun 2015 09:09, "Manu via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>
> On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> > On 1 Jun 2015 08:45, "Nick Sabalausky via Digitalmars-d" <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, 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?