KF5 Unit test results

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5