[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: meinproc4 on Mac, KLocale (was Re: What to test for 4.13?)
From:       Luigi Toscano <luigi.toscano () tiscali ! it>
Date:       2014-04-17 18:32:17
Message-ID: 53501E31.6060202 () tiscali ! it
[Download RAW message or body]

Ian Wadham ha scritto:
> Hello Thomas and Luigi,
> =

> Sorry it has been such a while since you wrote.  A lot of water has
> flowed under the bridge since then, but this issue is still of the utmost
> importance to MacPorts.  See:
> =

> https://trac.macports.org/wiki/KDEProblems/KDETickets
> =

> On 21/03/2014, at 11:52 PM, Thomas L=FCbking wrote:
>> On Freitag, 21. M=E4rz 2014 08:24:06 CEST, Ian Wadham wrote:
>>
>>> That call to KGlobal::locale(); seems an odd one, KDE guys.  That funct=
ion is supposed to
>>> return a locale (KLocale *), but here it is executed as a procedure, ig=
noring the return
>>> result.  I can only conclude that the code is being executed for its si=
de-effects:
>>
>> It will likely be to call protected KLocale::initInstance(), eventually =
to intantiate it from the main thread for sure.
>>
>> Not sure if it's required at all - look at the date of the commit!
>>
>> commit 693da1d1df4876d7c898f3035beead76288872d5
>> Author: Stephan Kulow <......@kde.org>
>> Date:   Fri Jul 6 15:19:46 2001 +0000
>>
>>   update to docbook-xsl 1.40
>>
>> [....]
>>
>> -    KGlobal::locale()->setMainCatalogue("kio_help");
>> +    KLocale::setMainCatalogue("kio_help");
>>    KInstance ins("meinproc");
>> +    KGlobal::locale();
>>
>> [=85.]
> =

> I hesitate to touch even one line of code from Stephan, one of the all-ti=
me greats
> of KDE, but I think that is what I am going to have to do.  I wrote to Al=
bert Astals Cid,
> to find out if meinproc4_simple could do the job of producing KDE Handboo=
ks on
> MacPorts and Apple OS X, but it can not: it does not include compression.
> =

> The best solution IMHO will be something like meinproc4_simple.  It would=
 bypass
> all the legacy code and just process command-lines of the form:
> =

>     meinproc4 [--check] [--cache] <HandbookPath>/index.cache.bz2 <Docbook=
Path>/index.docbook
> =

> which is what CMake's kde4_create_handbook() macro boils down to in the e=
nd.
> =

> The alternatives would be to re-work the mainline code of meinproc4 OR to=
 try
> and investigate these intermittent crashes across the four versions of Ap=
ple OS X
> and three Mac hardware architectures supported by MacPorts.  The crashes =
affect
> some people's Apple machines but not others --- and not mine, for example.

Thanks for looking into it, just to question here:
- did you try to just disable that line? It's certainly less "breaking" than
try to rewrite a tool where locale support have been rewritten in KF5. On t=
he
other side, if the call to that Mac system functions produces some issues, =
it
could potentially affect even newer applications (I haven't checked how Qt5
implements locale support).
- would it be possible to create such a map (combination of arch/SO where it
crashes)?

It "just" need a machine where the crash can be reproduced with a debug bui=
ld
and the debugger.


> That way, all the CMake stuff can stay the same as it is now.  The stripp=
ed-down
> meinproc4 would issue a warning message if it is given command-line synta=
x it
> cannot handle, but would NOT crash the whole build.
> =

> I think the best way might be to start off the code with something like:
> =

>     #ifndef Q_OS_MAC
>     #define MEINPROC4_FULL
>     #endif

Again, you just need to pass the language, if you disable that crashing lin=
e.
No need to "fork" the application just for MacOSX.

Ciao
-- =

Luigi


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]