Dub support was added to Meson

[Matthias Klumpp]

On Friday, 10 August 2018 at 14:38:10 UTC, Russel Winder wrote:
> On Sat, 2018-08-04 at 16:07 +0000, Filipe Laíns via 
> Digitalmars-d-announce wrote:
>> Hello,
>> 
>> Dub support was finally merged to the Meson's upstream.
>> For the ones that don't know, Meson[1] is a fast build system
>> that uses ninja[2] as a backend. Until now it was impossible to
>> use dependencies via the Dub and many many packages only
>> supported Dub. Now you can import dependencies that already 
>> exist
>> in Dub's local repo. You still need to fetch and build them
>> though.
>
> Sadly not in Meson 0.47.1 is a new release due soon?

There is no fixed release schedule, but from experience, this 
might take a few months.

>> First, you need to fetch and build the dependency.
>> 
>>    dub fetch vibe-d
>>    dub build vibe-d
>
> This feels a little unsatisfactory. Dub (and soon SCons I hope) 
> builds handle getting the dependency as well as building it and 
> thence linking the project to it. Meson both depends on the dub 
> executable and yet isn't doing the getting, it is assuming 
> already got.
>
> Of course Meson relies on all dependencies being present at 
> build specification time, so nothing inconsistent, it just 
> seems a wee bit incomplete.

This is intentional, see this comment from Jussi: 
https://github.com/mesonbuild/meson/pull/3592#issuecomment-390421754

Unfortunately, this makes the dub feature almost useless for 
Linux distro integration.
However, I hope we might be able to implement reading dub.json 
files that are locally installed and incorporate D sources from 
the dependency into the regular Meson build process.

This would mean that Meson's dlang plugin would have to implement 
quite a bit of dub and dub.json parsing, which is some effort.
The benefit would be the creation of a near-seamless bridge 
between the dub and Meson worlds (you'd only have to locally 
install a dub package), that is also useful for Linux 
distribution packaging.

> [...]
> I have been getting projects such as Unit-Threaded, DInotify, 
> TinyEndian, and D_YAML to have Meson builds so as to create 
> shared libraries prior to using pkg-config to handle D project 
> being dependent on these libraries. It's working nicely (for me 
> anyway) except Dub uses GitHub tags for versioning and Meson 
> requires version numbers in the meson.build file. This 
> duplication is getting quite annoying for all concerned. As is 
> the Meson requirement to list all source files, rather than 
> have a convention over configuration approach as Dub does – 
> SCons has a different approach but still avoids explicit source 
> lists. I can get round it with Meson, but I am informed it is 
> naughty and should not be done.

Jup, deterministic source lists are useful for split-building 
stuff efficiently. And globbing sources is possible with Meson, 
but highly discouraged (and even looks ugly).

> These builds create shared objects and allow for dynamic 
> linking. Using Dub built archives means static linking. Unless 
> Meson somehow manages to get shared objects out of the Dub 
> build.
>
> Unless Dub can generate shared objects, having the dependencies 
> build locally and creating pkg-config files actually seems a 
> better way that accessing Dub builds.
> [...]

At the moment, I think for a final project, adding Meson files to 
dependencies still is the better way. However, for quickly 
testing out things and for building something locally, the new 
dub support is quite valuable.
Also, we can expand it in future, this is a first step :-)