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.
