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übking wrote: > On Freitag, 21. März 2014 08:24:06 CEST, Ian Wadham wrote: > >> That call to KGlobal::locale(); seems an odd one, KDE guys. That function >> is supposed to >> return a locale (KLocale *), but here it is executed as a procedure, >> ignoring the return >> result. I can only conclude that the code is being executed for its >> side-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(); > > [….] 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 Albert 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 bypass all the legacy code and just process command-lines of the form: meinproc4 [--check] [--cache] <HandbookPath>/index.cache.bz2 <DocbookPath>/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 try and investigate these intermittent crashes across the four versions of Apple 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. 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 stripped 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 unsubscribe <<
