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