Dub support was added to Meson

[Filipe Laíns]

On Friday, 10 August 2018 at 14:38:10 UTC, Russel Winder wrote:
>> 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.

Yeah, Meson is a build system, not a package manager. This 
problem can be solved by simply creating a script that fetches 
and builds de dependencies. When creating a script, you might 
also want to compile the dependencies against the system's 
default D compiler. This way, you won't have any issues.

> I haven't finished reading the Meson source to find out which 
> Dub built archive is used in the Meson build but if it is the 
> one in ~/.dub/packages/<package>-<version>/<package> then stuff 
> can go wrong since it is the result of the last build. In order 
> to get the build with the specific compiler on the specific 
> platform you have to delve into 
> ~/.dub/packages/<package>-<version>/<package>/.dub/ and know 
> the Dub naming strategy. For SCons I am having problems with 
> this because of the extra stuff in the directory name.

It uses 'dub describe' to find the files, this also allows us to 
check the compiler. Meson won't even let you try to compile the 
project if there's an compiler mismatch.

> 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.

I mean, you can do this but as you said, it's not recommended.

> 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.

Dub is implemented this way for a reason. We really *shouldn't* 
use dynamic libraries, at least for now.