On Wednesday 05 September 2012 17:45:32 Chusslove Illich wrote: > >> [: Chusslove Illich :] > >> Now all work: Totals: 9 passed, 0 failed, 0 skipped. > > > > [: David Faure :] > > Damn it, so you won't be able to help me debug why it fails for me :( > > How about if you stick an i18n call into kde4-config (my favorite for this > purpose :), maybe tests do something funny with the environment? If that > doesn't work either, I'd try pure Gettext call within kde4-config, and also > within pure C code: > > #include <stdio.h> > #include <locale.h> > #include <libintl.h> > int main () > { > setlocale(LC_ALL, "fr_FR.utf8"); > bindtextdomain("kdelibs4", "/usr/share/locale"); > printf("%s\n", dgettext("kdelibs4", "Loadable modules")); > return 0; > }
Thanks, your testcase rocked. I found the issue. The problem was that the dgettext() in kcatalog.cpp was defined to a no-op in our gettext.h header, because ENABLE_NLS wasn't defined. This was because of recent changes which moved config-localization.h from kdecore to kdecore/localization, so I had an old incomplete config-localization-h in kdecore, which didn't define ENABLE_NLS. Yet another case where #cmakedefine01 saved the day: I saw the warning about it not being defined, during compilation. This also explains why it suddenly worked for you after a clean build. This makes me wonder: do we still need ENABLE_NLS? It makes kdecore (ki18n soon) compile even if libintl isn't found. Talking to Coolo, he said this was added for Solaris 0.3, back in the days :-) I think these days, if someone forgets to install libintl.h, we should rather abort and tell them. Coolo agreed. Any objections if I remove the no-NLS code path? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel