GNOME Bugzilla – Bug 622991
Use upstream gettext
Last modified: 2018-05-24 12:30:28 UTC
Patch following
Created attachment 164774 [details] [review] Use upstream gettext I can't fully test the patch as make distcheck currently fails in /gsettings/l10n test
Created attachment 177766 [details] [review] Use upstream gettext instead the Glib one.v2 Updated patch against current master
Created attachment 187907 [details] [review] Use upstream gettext instead the Glib one.v3 Updated patch against current master
Created attachment 189795 [details] [review] Use upstream gettext instead the Glib one.v4 Updated patch agains current master
I don't want to use upstream gettext as long as it causes 'unclean tree' disease.
Created attachment 220725 [details] [review] Use upstream gettext instead the Glib one.v5 New patch, now with a solution for the 'unclean tree' disease.
I'm not a big fan of this gross hack... What advantages do we gain by switching to 'upstream' gettext, anyway?
Created attachment 220732 [details] [review] Use upstream gettext instead the Glib one.v6 This is the good one. Advantages? Maybe use a po/Makefile.in.in file that is actively maintained by the gettext developers for example.
Hi! Only to keep the people up-to-date in case anyone is interested: This was the proposal from gettext developers: http://lists.gnu.org/archive/html/bug-gettext/2013-07/msg00007.html BTW, now reading the previous comment I realize I sounded a bit harsh, sorry about that, It was not my intention!
*** Bug 343885 has been marked as a duplicate of this bug. ***
FYIW, the new gettext 0.19 finally support adjust the behavior of updating PO files on demand: http://lists.gnu.org/archive/html/bug-gettext/2014-06/msg00000.html " * The po/Makevars file has a couple of new options PO_DEPENDS_ON_POT and DIST_DEPENDS_ON_UPDATE_PO, that can be used to adjust the behavior of updating PO files on demand. " I will update the previous patch as soon as possible to use the new functionality
Created attachment 280755 [details] [review] Use upstream gettext instead the Glib one.v7 This patch uses upstream gettext but avoid the 'unclean tree' disease using the new gettext options: PO_DEPENDS_ON_POT and DIST_DEPENDS_ON_UPDATE_PO
Created attachment 318592 [details] [review] Use upstream gettext.v8
Review of attachment 318592 [details] [review]: ::: autogen.sh @@ +31,1 @@ gtkdocize --copy || exit 1 So we don't need gettexttize at all anymore ? ::: configure.ac @@ +188,2 @@ # i18n stuff +AM_GNU_GETTEXT_VERSION([0.19.6]) 0.19.6 is very recent (September 2015) ::: po/Makevars @@ +52,3 @@ +# package uses functions taking also a message context, like pgettext(), or +# if in $(XGETTEXT_OPTIONS) you define keywords with a context argument. +USE_MSGCTXT = no This is wrong - glib/gdatetime.c uses C_()
(In reply to Matthias Clasen from comment #15) > Review of attachment 318592 [details] [review] [review]: > > ::: autogen.sh > @@ +31,1 @@ > gtkdocize --copy || exit 1 > > So we don't need gettexttize at all anymore ? No, autoreconf will call 'autopoint' if needed to generate the required files (po/Makefile.in.in and others) > ::: configure.ac > @@ +188,2 @@ > # i18n stuff > +AM_GNU_GETTEXT_VERSION([0.19.6]) > > 0.19.6 is very recent (September 2015) Agree, only 0.19.2 is needed; Sorry, somehow I managed to send a patch for a different module, will attach the correct one next > ::: po/Makevars > @@ +52,3 @@ > +# package uses functions taking also a message context, like pgettext(), or > +# if in $(XGETTEXT_OPTIONS) you define keywords with a context argument. > +USE_MSGCTXT = no > > This is wrong - glib/gdatetime.c uses C_() Corrected
Created attachment 318595 [details] [review] Use upstream gettext.v9
Review of attachment 318595 [details] [review]: I'm not super happy that this adds more shell and m4 crap (config.rpath and nls.m4 and its ilk), but what can you do...
Review of attachment 318595 [details] [review]: Thanks for the review; committed in e5c752371c7fb1343eff27b5f1d0bcbef4e333b9
Attachment 318595 [details] breaks glib --enable-gtk-doc build on FreeBSD: gmake[4]: Entering directory '/home/lantw44/gnome/source/glib/docs/reference/gobject' DOC Scanning header files DOC Introspecting gobjects ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_dngettext' ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_textdomain' ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_dcgettext' ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_bindtextdomain' ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_dgettext' ../../../glib/.libs/libglib-2.0.so: undefined reference to `libintl_gettext' clang: error: linker command failed with exit code 1 (use -v to see invocation) Linking of scanner failed: Makefile:861: recipe for target 'scan-build.stamp' failed gmake[4]: *** [scan-build.stamp] Error 1 libglib-2.0.so contains undefined symbols from libintl, but it doesn't list libintl.so.8 in NEEDED.
I've tagged glib in gnome-continuous: http://build.gnome.org/continuous/buildmaster/builds/2016/01/10/23/build/log-gnome-settings-daemon.txt It looks like we stopped installing glib-gettextize or so?
Yeah, looks like we need at least this hunk: - if test "$(PACKAGE)" = "glib"; then \ - $(MKINSTALLDIRS) $(DESTDIR)$(gettextsrcdir); \ - $(INSTALL_DATA) $(srcdir)/Makefile.in.in \ - $(DESTDIR)$(gettextsrcdir)/Makefile.in.in; \ - else \
(In reply to Colin Walters from comment #21) > I've tagged glib in gnome-continuous: > > http://build.gnome.org/continuous/buildmaster/builds/2016/01/10/23/build/log- > gnome-settings-daemon.txt > > It looks like we stopped installing glib-gettextize or so? yes, seems so: seems the po/Makefile.in.in that used to be part of glib has a modification to install stuff in /usr/share/glib-2.0/gettext: https://git.gnome.org/browse/glib/tree/po/Makefile.in.in?id=c1e2a8d72766323181c804b47547242bd70460e9#n166 . Compare with upstream gettext: http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/po/Makefile.in.in#n252 So I think glib will no be able to use upstream gettext because packages that are still using the AM_GLIB_GNU_GETTEXT macro in configure.ac will expect stuff in /usr/share/glib-2.0/gettext (is hardcoded in https://git.gnome.org/browse/glib/tree/po/Makefile.in.in?id=c1e2a8d72766323181c804b47547242bd70460e9#n33) Maybe we could fix this including the po/Makefile.in.in file in the glib tree and modifying it to install the files in /usr/share/glib-2.0/gettext as well, but maybe the best solution is to revert this for now. Thoughts?
(In reply to Javier Jardón (IRC: jjardon) from comment #23) > Maybe we could fix this including the po/Makefile.in.in file in the glib > tree and modifying it to install the files in /usr/share/glib-2.0/gettext as > well, but maybe the best solution is to revert this for now. Thoughts? If we're not going to fix this today, I think revert and try again later is the right thing to do.
(In reply to Colin Walters from comment #24) > (In reply to Javier Jardón (IRC: jjardon) from comment #23) > > > Maybe we could fix this including the po/Makefile.in.in file in the glib > > tree and modifying it to install the files in /usr/share/glib-2.0/gettext as > > well, but maybe the best solution is to revert this for now. Thoughts? > > If we're not going to fix this today, I think revert and try again later is > the right thing to do. Keeping po/Makefile.in.in in tree and modify it is not an option because it gets overwrite by autopoint. In lack of ideas for a solution I decided to revert the patch in commit 4e78a0a9df45961701d224326fbb9b93dcecf134
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/317.