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

[David Nadlinger via Digitalmars-d]

On Monday, 10 April 2017 at 17:27:28 UTC, Matthias Klumpp wrote:
> That's why I have been writing a lot of Makefiles and Meson 
> build definitions lately.

It seems like doing so without having a closer look at the 
realities of D software (no stable ABI, etc.) might not have been 
the best use of your time. How would Dub be such fundamentally 
unfixable that making the official language tools play nice with 
distro packaging (and the other way round) wouldn't be preferable 
over manually re-writing build systems all over the place?

> But with an unstable ABI the standard library is also affected, 
> which would trigger us to do Haskell-style versioning (which 
> mangles dependencies to depend on a virtual package containing 
> a hash of the GHC version), and that not only sucks but also 
> requires quite a lot of manpower.

So it sounds like there is a solution already for other 
languages. Could you elaborate some more on the problems with it? 
I suppose there is some wiki page documenting the process 
somewhere?

> Rust only has one compiler which strongly optimizes, so we 
> don't have the problem of choosing the right one. Cargo is/was 
> an issue but it's being worked on and seems to work well now: 
> https://wiki.debian.org/Teams/RustPackaging/Cargo

Rust doesn't have a stable ABI either, and it doesn't look like 
there is any movement in that direction (not that I think that 
there should be). That the people driving the effort might not be 
aware of it yet doesn't mean it isn't an issue for them.

IIRC OCaml is also very much a statically linked affair. And how 
does Debian distribute Go binaries? Is there any issue with those 
being linked statically? If not, let's just distribute D 
libraries as source and compile/link them statically when 
building binaries, and problem solved.

Some of the compiler developers, myself included, understand the 
issues involving ABI stability and distro packaging quite well 
(although the latter admittedly only on a general level). In 
fact, one of my earliest open source memories is of some work in 
the trenches ensuring ABI stability of some bits of KDE across 
releases. Yet we are still going to tell you that the D ABI is 
going to remain unstable for the foreseeable future. This is not 
something that just requires a man-week or month to "fix" in the 
compiler, but would impact many other areas as well, for example 
language evolution.

If you somehow got the impression that this is just due to D 
developers "not getting it", just have a look at the other recent 
compiled languages. Go and Rust don't fare any differently, and 
even Swift, with all its development manpower, doesn't have a 
stable ABI yet [1]. And I believe header-only C++ template 
libraries have been mentioned already as well.

I can only speak for myself, of course, but I certainly see the 
strategic importance of integration into the Linux distribution 
ecosystem for D, and I'm very happy to work with packagers 
wherever possible. However, you also need to acknowledge the 
properties of the ecosystem *you* are working with. If you see a 
big stretch of difficult terrain in front of you, closing your 
eyes won't make it go away; you'll only lose time you could spend 
working around it. ABI instability is something you'll have to 
work around one way or the other.

  — David


[1] Actually, the Swift guys tried to pin it down leading up to 
version 4, but in the end decided it was too much work to get 
done in time and possibly not a wise idea at this point 
altogether.