Meson support for Mir and Lubeck

[Matthias Klumpp]

[ Replying to lots of stuff in one message - evil, I know... ;-) ]

On Sunday, 9 September 2018 at 21:22:42 UTC, 9il wrote:
> On Sunday, 5 August 2018 at 02:36:29 UTC, Matthias Klumpp wrote:
>> [...]
>
> Looks like that only betterC projects are good enough to become 
> Debian packages. Generally because of the have stable C ABI 
> that does not depend on D compiler version at all.

Having a stable API/ABI is a *huge* plus, but we can also deal 
with pretty much any D library and D project in Debian, as long 
as it's build process is able to discover local dependencies and 
doesn't do evil stuff (like connecting to the network or writing 
to HOME).
It also has to build with LDC or have no D library dependencies 
and build with GDC (that's a bit oversimplified though).

In practice this means we can have dub projects with zero 
dependencies (except for the standard library) that build only 
executables in Debian packages with a bunch of hacks, or have any 
D project that uses Makefiles/Meson/CMake/Automake.
Mir has the latter now, so that's fine.


On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder wrote:
> On Sun, 2018-09-09 at 21:22 +0000, 9il via 
> Digitalmars-d-announce wrote:
>> 
> [...] Many Debian packages depend
> on specific versions of things like GCC runtime or LLVM. The 
> Debian packaging
> system allows for many versions of libraries to co-exists. Thus 
> supporting
> multiple versions of Druntime and Phobos is possible.

It is possible, but heavily discouraged, and also not something I 
would ever even try to do. Debian carries *one* version of 
Phobos/DRuntime per compiler that we support and that all D code 
in the archive has to build with.
There may be occasions where multiple versions are in the 
archive, but that happens only briefly during transitions.
For security reasons (only one thing to patch in stable) and 
maintainability reasons (the less to maintain the better) 
anything that doesn't build with the current version of D/Phobos 
will either be patched upstream or in Debian or dropped from 
Debian entirely.
So far this case has never happened though, all breakage of D 
code in Debian was usually addressed pretty quickly - except for 
strange compiler bugs on less common architectures.


>> 
> […]
>> > I only worry about potential name clashes with Mir (the 
>> > display server) in Ubuntu ^^
>> 
> This is going to be a naming problem. Debian has many of these 
> sort of naming clash and usually it is best for the smaller, 
> newer project to accept that they need to choose a non-clashing 
> name. Recent example the Mu editor, but there are many 
> instances of this. D's Mir needs to choose a name that doesn't 
> clash with Canonical's Mir.

This was more meant as a joke from my side ;-) Technically, 
nobody from Canonical bothered to upload a "mir" package to 
Debian yet, so technically the name is free to grab for us. 
However, introducing a src:mir package into Debian would either 
force Ubuntu to adapt and rename their display server source 
package (to mir-display-server) or not have D's mir for quite a 
while.
Socially I think claiming the src:mir name isn't the best idea, 
therefore - it's unfriendly to a derivative.
However, src:libmir is free and that's what we could go with as a 
pretty good compromise.
As for the binary package names, none of the D-mir names clash 
with Ubuntu's mir, so that's a non-issue.


On Monday, 10 September 2018 at 07:25:07 UTC, 9il wrote:
> On Monday, 10 September 2018 at 06:31:44 UTC, Russel Winder 
> wrote:
>> On Sun, 2018-09-09 at 21:22 +0000, 9il via [...]
>
> Interesting, maybe we can go forward with D specific libraries 
> in the future. Is there any D library that is used by 
> application packages?

Quite a few. Debian uses GDC and LDC for compiling its D 
packages. LDC on the amd64, arm64, armhf and i386 architectures 
and GDC on all other archs.
The respective default D compiler is set via the 
default-d-compiler metapackage[1].

This means that whenever there's a new compiler release, ABI gets 
broken "thanks" to D's unstable ABI. Fortunately all new 
compilers also come with a new Phobos shared library that has had 
its SONAME bumped. Which means we can track which D compiler a 
package was built with via the phobos/druntime libraries they 
link to.
This enables us to rebuild dependencies in order via a regular 
library transition, coincidentally one is going on right now. 
See[2] and tick "Good" to see all D packages that are part of 
this transition.

This results in the fun conundrum though that as soon as we have 
D code that *doesn't* link against druntime or phobos, we can't 
track whether it was rebuilt with the latest compiler and it 
might fall through the cracks.
I wonder how much of an issue this is - other languages 
implemented hacks to deal with this issue by depending on 
artificial virtual ABI packages denoting the current compiler 
version.

> Mir Optim can be easily used by other libraries and languages, 
> developers don't need to know D at all as well as depend on 
> DRuntime and D compiler.
>
> The problem with Compiler/DRuntime version that it seems like 
> that if, for example one man released library A that is depend 
> on DRuntime v1, and other man released library B that depends 
> on DRuntime v2, how can I use them in my project together if 
> this DRuntimes are not compatible at ABI level? Maybe we can 
> link dynamically them together, but how GC will work then (in 
> case of non BetterC library)?

In Debian, both libraries and all projects would either build 
with the latest DRuntime, be adjusted to build with it or be 
dropped from the distribution if they can't keep up.
So, this issue shouldn't exist.

> If a solution of this issue exist, I would be very surprised if 
> it is easy to go solution. betterC libraries with fixed ABI, 
> and C/C++ API looks to me like a right way to develop D 
> packages for Debian.

It certainly is nicer - but we deal with even worse languages 
than D when it comes to ABI instability. For example, Haskell and 
OCaml require a full rebuild of all packages even on minor 
compiler version changes. Therefore, virtual packages containing 
checksums of the compiler exist, it's quite insane. These 
languages are also in an eternal transition[3].
This works, because there are actually bigger teams behind those 
languages which can handle the work.

Which brings me to a new point:
Adding libraries to Debian for their own sage is sometimes done 
if someone is using them / is interested in them in itself, but 
often they get pulled in because another tool that is in Debian 
needs them.
Mir would be the former case, adding a library without something 
using it that's also in Debian.
I like the Mir project, but since I am not using it at the moment 
(as scientist I actually might be tempted to do so in future) and 
since I already have way too many packages to care for, someone 
else would need to step up and do the packaging work and - more 
importantly - the maintenance work.
While the Debian D team[4] officially lists 4 members, it's 
basically me doing all the work at the moment with Markos helping 
with LDC maintenance as its original maintainer.
So, tl;dr: I will help with reviewing packages and sponsoring 
packages into Debian, but in order to get the package in, someone 
would need to step up and do the work.

FWIW, the Debian D Team is not the only entity withing Debian 
maintaining D code, the GNOME Team has gtk-d, glib-d and tilix 
and the Debian Games team also has a bunch of D stuff and a bit 
is also in the Debian Med/Science team, but the majority of D 
code is concentrated in the D team.

Cheers,
     Matthias

[1]: https://packages.debian.org/sid/default-d-compiler
[2]: https://release.debian.org/transitions/html/auto-ldc.html
[3]: https://release.debian.org/transitions/html/haskell.html
[4]: https://salsa.debian.org/groups/d-team/

P.S: As for "D libraries in Debian", we have vibe.d, diet-ng, 
libundead, stdx-allocator, mustache-d, containers, glib-d, gtk-d, 
libbiod. Quite a bunch, actually!