glib-networking: Support building with USE_NLS=no
PATCH 1/1 glib-networking: Support building with USE_NLS=no
As reported in
http://lists.openembedded.org/pipermail/openembedded-core/2019-February/279344.html
, glib-networking no longer configures successfully if USE_NLS="no":
| po/meson.build:1:5: ERROR: Can not do gettext because xgettext is not installed.
In the current absence of anything better, it seems that this can be overcome by telling Meson not to look in the po/ directory.
--- .../glib-networking/glib-networking_2.60.2.bb | 10 ++++++++++ 1 file changed, 10 insertions(+)
meta/recipes-core/glib-networking/glib-networking_2.60.2.bb +10 -0
@@ -30,3 +30,13 @@ FILES_${PN} += "\ " FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la" FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a" + +# meson lacks support for --disable-nls. +disable_nls() { + sed -i "/subdir('po')/d" ${S}/meson.build +} + +do_unpack_append() { + if d.getVar('USE_NLS') == 'no': + bb.build.exec_func('disable_nls', d) +}
Signature · 1 line
2.20.1
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 30 lines · Mike Crowe
Quoted 5 lines · Ross Burton
Quoted 4 lines · Mike Crowe
As reported in
http://lists.openembedded.org/pipermail/openembedded-core/2019-February/279344.html
, glib-networking no longer configures successfully if USE_NLS="no":Quoted 8 lines
Quoted 4 lines
| po/meson.build:1:5: ERROR: Can not do gettext because xgettext is not installed.
In the current absence of anything better, it seems that this can be overcome by telling Meson not to look in the po/ directory.
Does this actually work? glib has the same issue (along with most of the rest of the GTK+ stack that has moved to Meson) and the solution there was to just add gettext as a dependency.
It seems to for me. I did this in our tree, but I've just tried this change and forcing
USE_NLS= "no" in the current state of master and the build succeeded.Quoted 2 lines
We're going to be playing whack-a-mole with this, maybe we should just fix this upstream?
Fixing it upstream in meson would clearly be preferable, but it seemed that this has already been tried. Fixing it in each meson-using package is another alternative, but it would be good for it to be done in the same way. I know little about meson. :(
As such hacks go, this is at the less nasty end. Perhaps it could even perhaps be incorporated into the meson class?
Quoted 7 lines
I've added a comment to https://github.com/mesonbuild/meson/issues/821 .
Mike.
(I'm not sure if you intentionally sent this off-list. I don't mind sending this reply again to the list if it was a mistake.)
No, I didn't send it off-list intentionally. New mailer :( CCing the list again now.
I wonder if patching in a disable-nls option that guards the subdir(po) would be sufficiently uninvasive and upstreamable to each project?
Ross
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.