Distributor's whishlist and questions for D
Matthias Klumpp via Digitalmars-d
digitalmars-d at puremagic.com
Wed Apr 20 18:01:01 PDT 2016
Hello!
Me bringing dub to Debian (and subsequently Ubuntu) has sparked
quite some interest in getting more D applications shipped in
Linux distributions.
Since I think D is a great language, I would welcome that - in
order to get more D code into distributions though, it would be
awesome to sort out a few issues which currently (seem to) exist.
So I created this list, first to raise a bit of awareness on the
issues that I see, and second - because I am very new to D - to
allow others to point out solutions to those problems, or explain
a different view on why some things are (not) done in a certain
way (yet).
While I am thinking from a Debian point of view, quite some stuff
is relevant for other distros as well.
So, let's get started:
## How complete are the free compilers?
This is an important question, because we would need to know
whether we can expect D code to be compiled by any compiler, or
whether there are tradeoffs that must be made.
This question is asking manly how complete LDC and GDC are
compared to each other, but also whether both are implementing
the D2 specification completely.
The question here is also, which compiler should be the default
(which IMHO would be the most complete, most bug-free actively
maintained one ^^).
## Why is every D compiler shipping an own version of Phobos?
If one assumes that the D2 language specification is stable, and
D compilers implement it completely, the question is why every
compiler is shipping an own copy of Phobos. This is a major pain,
since e.g. GDCs Phobos is behind what is documented on dlang.org,
but also because the compilers sometimes accidentally use the
"wrong" Phobos version (e.g. GDC trying to use the one of LDC),
leading to breakage.
Also, distributors hate code duplication, so deduplicating this
would be awesome (druntime being compiler-specific makes sense to
me, Phobos not so much...).
It's not an essential thing, but would be quite nice...
## Where should D source-code / D interfaces be put?
If I install a D library or source-only module as a distribution
package, where should the sources be put? So far, I have seen:
* /usr/include/d
* /usr/include/dlang/
* /usr/include/d/(dmd|gdc|ldc)
* /usr/share/dlang
Having one canonical path would be awesome ;-)
## dub: Where should dub modules be installed?
DUB currently only searches online for it's packages, but if we
install them as distributor, we want dub to also look locally in
some path where the packages can be found, and - if possible -
use a prebuilt shared/static library.
(reported as https://github.com/dlang/dub/issues/811 )
## dub: How to install modules?
Ideally, dub would also have a "dub install" command, to install
the binary, "headers (.di)"/sources and data into standard
directories on Linux.
(reported as https://github.com/dlang/dub/issues/811 )
++++++
Aside from these things, there are also some other things which
would be very useful:
## Shared library support in all compilers
In distributions, we hate duplicating binary code copies. At
time, D links everything statically, which means that when a bug
is discovered in a library used by many other tools (worst case:
the standard library), we will need to recompile all depending
software.
This is really annoying for the security team, while not being as
bad as having actual duplicate source-code copies which need to
be patched individually.
## Stable ABI among compilers
Simple: Compile your library with GDC, have it used by code
compiled with LDC. Otherwise, shared libraries would be of very
limited use.
Cheers,
Matthias
More information about the Digitalmars-d
mailing list