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)
- The D ecosystem in Debian with free-a... Matthias Klumpp via Digitalmars-d
-
