[vdr] sequence of messages in xgettext/msgmerge
I'm just trying to build VDR on openSUSE 11.4, which comes with xgettext/msgmerge version 0.18.1. For some odd reason, when doing make i18n the sequence of the messages in the *.po files is completely different than before, which would cause a huge and unnecessary diff in the next developer version of VDR. Does anybody know if the gettext-tools have been broken at some point? Is there a way to get the previous sequence of messages back? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sequence of messages in xgettext/msgmerge
On 15 May 2011 13:58, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I'm just trying to build VDR on openSUSE 11.4, which comes with xgettext/msgmerge version 0.18.1. For some odd reason, when doing make i18n the sequence of the messages in the *.po files is completely different than before, which would cause a huge and unnecessary diff in the next developer version of VDR. Does anybody know if the gettext-tools have been broken at some point? Is there a way to get the previous sequence of messages back? FYI Ubuntu natty similar has 0.18.1 but doesn't change the order of messages in the .po files when doing make i18n (at least not on the 1.7.18 snapshot). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
On 14.05.2011 13:06, Tobi wrote:
On 13.05.2011 23:47, Udo Richter wrote:
Am 13.05.2011 07:44, schrieb Tobi:
Interestingly irritating... Since I don't have an GCC4.6 at hand, I
*think* the source of the problem might be that cCursesFont has just an
default constructor.
Right. The C++ standard explicitly requires an user-declared default
constructor here.
So it should also work if you add an empty
constructor cCursesFont::cCursesFont() { } ???
Yes. Either this or -fpermissive. But personally I prefer the initializer
here, but I must admit I don't understand the technical reason, why the
standard requires a user defined default constructor at all.
I also have to admit that I don't understand what difference this makes.
Apparently the program works, so the initialization must be taking place,
even without explicitly calling cCursesFont().
At any rate, I've adopted the patch.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
Am 15.05.2011 23:45, schrieb Klaus Schmidinger:
On 14.05.2011 13:06, Tobi wrote:
Right. The C++ standard explicitly requires an user-declared default
constructor here.
So it should also work if you add an empty
constructor cCursesFont::cCursesFont() { } ???
Yes. Either this or -fpermissive. But personally I prefer the initializer
here, but I must admit I don't understand the technical reason, why the
standard requires a user defined default constructor at all.
I also have to admit that I don't understand what difference this makes.
Apparently the program works, so the initialization must be taking place,
even without explicitly calling cCursesFont().
What makes this even more strange to me is the fact, that
static const cCursesFont Font;
requires an user-declared default constructor, while
static const cCursesFont Font = cCursesFont();
creates an temporary non-const cCursesFont object, and then uses the
implicitly declared copy constructor to create the final Font object. So
why is the implicitly declared default constructor forbidden, and the
implicitly declared copy constructor ok?
You'll really need an lawyer when it comes to standards specifications...
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
