From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
Anuj Mittal <anuj.mittal@intel.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/2] glib-networking: upgrade 2.54.1 -> 2.58.0
Date: Sat, 23 Feb 2019 09:36:19 +0000 [thread overview]
Message-ID: <4171dd4196ea514bac20b44b37ebf28acc1958eb.camel@linuxfoundation.org> (raw)
In-Reply-To: <0414b3b6a2c7404883f691c4198b8007@XBOX04.axis.com>
On Thu, 2019-02-21 at 23:46 +0000, Peter Kjellerstedt wrote:
> This does not build any more if USE_NLS = "no" is used. Has anyone
> looked at making this work together with meson? Otherwise I guess
> there is trouble ahead now that more and more packages are being
> converted to use meson, since the code in gettext.bbclass currently
> only supports autotools. A quick look at meson's i18n.py module does
> not indicate that there is any easy way to disable the gettext
> support, corresponding to autotools' --disable-nls. Apparently it
> was discussed in https://github.com/mesonbuild/meson/issues/821, but
> it seems they only added detection of the gettext tools without
> adding support for disabling gettext and then closed the issue.
>
> Looking at 1d6648102 (json-glib: fix native build), it seems Ross
> encountered a similar problem for json-glib and opted to workaround
> the problem by overriding USE_NLS. However, that does not seem like
> a long term solution...
Once, we did have people who had interests in these things *and* time
to be able to go and work on them. The way things are at the moment,
the people who would have once done this are no longer available.
I agree this would be nice to have and we do rely on it for some parts
of the build system but it will need someone to step up and work on it.
I don't know how to attract more people to help with these kinds of
things, I think over time things will improve but we are struggling a
bit with it right now.
It is worth opening a bug for so we can track it.
If someone had time to talk to upstream meson, that would also be
useful, see if we can convince them its a good idea.
Cheers,
Richard
prev parent reply other threads:[~2019-02-23 9:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-20 7:12 [PATCH 1/2] libjpeg-turbo: upgrade 2.0.1 -> 2.0.2 Anuj Mittal
2019-02-20 7:12 ` [PATCH 2/2] glib-networking: upgrade 2.54.1 -> 2.58.0 Anuj Mittal
2019-02-21 23:46 ` Peter Kjellerstedt
2019-02-23 9:36 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4171dd4196ea514bac20b44b37ebf28acc1958eb.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=anuj.mittal@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=peter.kjellerstedt@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox