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.
