On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:
Yeah, I was pointing at the lock-step upgrade nature of D
development. You can't really update one without the other
when it comes to every day package management.
True. This why I have them all in a single PKGBUILD (ebuild
analog I guess) despite those looking separate in package manager.
> - Tools tend to expect that "dmd" is available as a command.
Actually I don't think this is true for newer ones. There are
plenty that tend to either use `rdmd` or detect compiler
present in the system.
Good, the only thing that might go wrong then is alternate
binary names or install locations.
Well the idea is simple - whatever install locations are,
packager provides default /etc/dmd.conf (ldc has similar conf
file and gdc needs to be patched during build) that allow plain
compiler invocations to "just work" without figuring out any
actual path. I also have common base path for all D modules
installed via `pacman` - "/usr/include/dlang/" which is in
default `-I` list so that any library installed that way can be
directly imported with no extra steps.
Your experience is welcome! Does D1 have a place in that
model?
AFAIK no one uses D1 but company I am working for :P
And what does really happen when you work with e.g.
dmd-2.065 and found a D application in the tree that hasn't
been updated for a few weeks, so it still requires 2.064?
It is somewhat easier in Arch case as core repositories provide
pre-compiled binary packages. So it does not really matter what
compiler version is required for application if it is statically
linked and is not a library on its own. For source-based packaged
(AUR in Arch case) I'd send a pull request upstream :) Or mark it
out-of-date and wait :)
It would more or less mean that the whole D package system
would have to be updated in one go, when all packages are
updated to the latest D version, which can take a while.
It is pretty much what happens right now anyway as it is defined
by nature of D versioning / releases and there is not much we can
do about it :)
> Next a symlink should be established to the current
> implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.
> This symlink could be managed with an eselect plugin as it is
> already done for other languages like Python or the Java
> Runtime.
And what if one wants to have all 3 simultaneously?
You call them by their real names. :)
Well, "dmd" IS real name for dmd ;) In that sense that "dc"
proposal makes much more sense.
