Meson support for Mir and Lubeck

[9il]

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:
>> 
> […]
>> 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.
>
> I do not follow the logic here at all. Any and all projects 
> with a CMake,
> Meson, SCons, even Make build be Debian packages. 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.

Interesting, maybe we can go forward with D specific libraries in 
the future. Is there any D library that is used by application 
packages?

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)?

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.

>> 
> […]
>> > 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.

We can choose other library prefix for packages instead of "mir", 
say "mirmodule", so it would be libmirmodule-optim. Would this 
work? I don't have resource to rename all mir and dependencies.