On Monday, 19 February 2018 at 10:08:37 UTC, Martin Nowak wrote:
On 02/17/2018 06:52 AM, Eugene Wissner wrote:
On Friday, 16 February 2018 at 11:25:42 UTC, Martin Nowak wrote:
On 02/10/2018 09:17 AM, Thomas Mader wrote:
https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2.

Out of curiosity, do you have a strong use-case to install/update dub separately of the compiler?

I'm shipping dub (as a part of d-tools package) separately from the compiler for Slackware Linux. This way it can be built with the compiler of choice: dmd, gdc or ldc. It doesn't always make sense to ship dub with every compiler since you can use --compiler option. And the compiler dub is built with, is the default compiler to build dub projects.

You have any idea for a more sensible default compiler? IIRC dub now supports any compiler out of the box, but indeed the search order depends on it's host compiler.

The main goal of shipping dub with the compiler was to simplify distribution and increase it's usage. Would you say this goal is met, or should we consider to release dub binaries separately but in sync with dlang releases.

It would be great if dub had some global configuration file /etc/dub.conf (or dub.json) for example, where the defaults can be set (I don't know if something like this already exists), or maybe /etc/d/ where dub.conf and dmd.conf can be put - it seems a bit cleaner to me.

I think that shipping dub and dmd together is generally a good thing. I'm using Ubuntu at work and I'm pretty happy that I can just download one package and get the main d tools installed together. One of the things I hate about the most deb/rpm based distributions, is that the most programs are split in a lot of small packages. As for Slackware I want to switch to building dmd from source anyway, so I think it doesn't matter a lot for maintainers that binary packages have dub as well. And for normal people it's just simpler to install everything together as you said.

Reply via email to