The D ecosystem in Debian with free-as-in-freedom DMD

[Matthias Klumpp via Digitalmars-d]

Hi there!
These are probably questions directed mostly at Walter and others 
shaping D's goals, but this could be of general interest for many 
people, so to the forum it goes :-)

DMD is completely free software now and we can legally distribute 
it in Debian main - yay! This is an awesome achievement and will 
make D adoption in Linux distributions much easier (in fact, Red 
Hat is working on getting good support into Fedora too already).

There are a two issues though that we will be facing in Debian 
soon, and I would like to get some opinion and maybe perspective 
on from the D community on them.

Naturally, when the reference compiler is available in Debian, we 
would compile everything with that, as it is the development 
focus and the thing many people test with.
We do, however, have quite a bit of bioinformatics and other D 
software in the archive where performance matters - so our users 
and the developers of that software (like BioD, potentially Mir, 
maybe even Vibe.d) will want the fastest performance and will ask 
us to compile the libraries with LDC or GDC.

If we do that, we will run into the D ABI trap: Libraries 
compiled with compiler X can not be used from software compiled 
with D compiler Y. There is actually no ABI stability guarantee 
even between DMD releases.
This will make integrating D a huge pain. Recompiling the 
dependency-chain of a software from source when compiling a 
package using the "right" compiler and statically adding the code 
is forbidden by distro policy. Having static libraries in the 
dependencies doesn't solve the issue. Compiling each library with 
all D compilers is highly impractical and not really feasible.
So, how should we proceed here? We could make it "DMD is the only 
thing on the highway" compiling everything with DMD with zero 
exceptions, which would leave us with only DMD-internal ABI 
breakage and bad D code performance for some libraries. We could 
also continue using LDC for everything, but that comes with it's 
own issues (I am hitting quite a bunch of LDC bugs and upstream 
projects usually test with DMD or use features which are only in 
the latest DMD).

The other issue is architecture support. In Debian we are 
strongly encouraged to support as many architectures as possible, 
to the point of having to justify why arch X is not supported.
LDC runs on at least armhf and ppc64el additionally to 
amd64/ia32, while DMD says it's specifically only for ia32/amd64.
This means we might end up compiling stuff with different D 
compilers on different architectures, or we will need to drop 
architectures and request arch-specific package removals for 
things that currently build on architectures not supported by 
DMD, which will trigger resistance.

So, in summary:
   1) Is there some perspective on D getting a defined ABI that 
works with all major D compilers?
   2) What would the D community recommend on how to deal with the 
ABI issues currently? A Linux distribution is a bunch of tightly 
integrated software, and changing one piece in an incompatible 
way (e.g. by building it with LDC instead of DMD) will have 
consequences.
   3) Will DMD support more architectures in the near future? How 
should the architecture issue be handled?

I am interested in some feedback here, since I currently can't 
see a good way to address these issues.

Also: If you want to help out Debian's D team, feel free to ping 
me or any other D team member (we are very short handed and are 
only two active people right now). See https://wiki.debian.org/D 
(caution, wiki page is very outdated, last touched in 2012)