After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794709 - meson: allow wrapping glib-networking as a subproject
meson: allow wrapping glib-networking as a subproject
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: network
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2018-03-26 21:35 UTC by Mathieu Duponchelle
Modified: 2018-03-28 19:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
see commit message (3.07 KB, patch)
2018-03-26 21:35 UTC, Mathieu Duponchelle
committed Details | Review

Description Mathieu Duponchelle 2018-03-26 21:35:14 UTC
Created attachment 370165 [details] [review]
see commit message

Provide fallbacks to the required dependencies, and specify implicit dependencies (gobject, gmodule), as this is required when building against an internal dependency with meson.
Comment 1 Michael Catanzaro 2018-03-26 22:39:31 UTC
Review of attachment 370165 [details] [review]:

Can you explain a bit what this does and how it is expected to work?

::: meson.build
@@ +55,3 @@
+if glib_dep.type_name() == 'internal'
+  glib_proj = subproject('glib')
+  gio_module_dir = glib_proj.get_variable('glib_giomodulesdir')

This will result in installing outside the build prefix, which is not OK.
Comment 2 Mathieu Duponchelle 2018-03-28 10:21:06 UTC
(In reply to Michael Catanzaro from comment #1)
> Review of attachment 370165 [details] [review] [review]:
> 
> Can you explain a bit what this does and how it is expected to work?
> 
> ::: meson.build
> @@ +55,3 @@
> +if glib_dep.type_name() == 'internal'
> +  glib_proj = subproject('glib')
> +  gio_module_dir = glib_proj.get_variable('glib_giomodulesdir')

This is obtaining the glib_giomodulesdir variable from the glib subproject, if the glib dependency is "internal", ie is getting built as another subproject alongside glib-networking.

> 
> This will result in installing outside the build prefix, which is not OK.

It will not, this variable is the one that is passed when building glib's pc file, for reference when building without specifying a prefix, its value is "/usr/local/lib/gio/modules", which is OK
Comment 3 Michael Catanzaro 2018-03-28 15:57:28 UTC
(In reply to Mathieu Duponchelle from comment #2)
> This is obtaining the glib_giomodulesdir variable from the glib subproject,
> if the glib dependency is "internal", ie is getting built as another
> subproject alongside glib-networking.

I don't understand: what does this mean? Is there meson documentation for it? glib-networking is not a subproject nor does it have any subprojects.

> > This will result in installing outside the build prefix, which is not OK.
> 
> It will not, this variable is the one that is passed when building glib's pc
> file, for reference when building without specifying a prefix, its value is
> "/usr/local/lib/gio/modules", which is OK

That's actually not OK, that's a meson bug. When glib is built with Autotools, you'll notice the definition of giomodulesdir is relative to other pkg-config variables (libdir and prefix) and so can be adjusted relative to a new prefix. When built with meson, we just get a hardcoded path.

glib's prefix can be different from glib-networking's prefix, and we want to always install under glib-networking's prefix: that's why we have to redefine the pkg-config variable. I'm going to make this patch as needs-work for this reason. If glib is built with meson, then you cannot look at the pkg-config variable at all until meson is fixed. In the meantime, you'll just have to hardcode the proper path here.
Comment 4 Michael Catanzaro 2018-03-28 15:58:06 UTC
(In reply to Michael Catanzaro from comment #3)
> I'm going to make this patch as needs-work
> for this reason.

I meant "mark"
Comment 5 Mathieu Duponchelle 2018-03-28 17:28:23 UTC
You might want to take a look at meson's documentation for subprojects, I don't think it is the role of the patch to explain how meson works :)

In the case where glib is built as a subproject *alongside* glib-networking, they will share the same prefix, making your concerns unfounded.
Comment 6 Michael Catanzaro 2018-03-28 17:46:39 UTC
Review of attachment 370165 [details] [review]:

OK, fair enough
Comment 7 Mathieu Duponchelle 2018-03-28 17:51:02 UTC
Thanks :)