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