[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:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-04-17 7:19:14
Message-ID: DB1E3D05-6494-4078-9868-E525AF6A2A88 () gmail ! com
[Download RAW message or body]

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 functi=
on is supposed to
>> return a locale (KLocale *), but here it is executed as a procedure, ign=
oring the return
>> result.  I can only conclude that the code is being executed for its sid=
e-effects:
> =

> It will likely be to call protected KLocale::initInstance(), eventually t=
o 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-time=
 greats
of KDE, but I think that is what I am going to have to do.  I wrote to Albe=
rt Astals Cid,
to find out if meinproc4_simple could do the job of producing KDE Handbooks=
 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 b=
ypass
all the legacy code and just process command-lines of the form:

    meinproc4 [--check] [--cache] <HandbookPath>/index.cache.bz2 <DocbookPa=
th>/index.docbook

which is what CMake's kde4_create_handbook() macro boils down to in the end.

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

The question remains of how to present the source-code.  Rather than write a
separate source file and build a separate executable, with a different name,
as has been done with meinproc4_simple, I am thinking of using conditional
code to produce an executable that is either the full meinproc4 or a stripp=
ed
down meinproc4, for use in Apple OS X builds only.

That way, all the CMake stuff can stay the same as it is now.  The stripped=
-down
meinproc4 would issue a warning message if it is given command-line syntax =
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

then use #ifdef MEINPROC4_FULL or #ifndef MEINPROC4_FULL to control
what gets complied on Apple OS X or elsewhere.  The idea is that one could
define MEINPROC4_FULL externally on Apple OS X and still get the full
version of meinproc4 if it was needed.

Please let me know what you think of these ideas.  Please also let me know
what group(s) or individual(s) to post to on ReviewBoard for this work.

Cheers, Ian W.


>> 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]