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