[KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends

[Ian Wadham]

On 12/02/2015, at 10:34 AM, Brandon Allbery wrote:
> On Wed, Feb 11, 2015 at 6:31 PM, René J.V. <rjvbertin at gmail.com> wrote:
> I take that to mean that doing fork() doesn't oblige you to do an exec() afterwards, it's that you cannot do a fork() from a process that's not been started through exec.
> 
> I will guess that this is related to the fact that such processes are actually started by launchd, and must play by launchd's rules (including not using fork()) so launchd can keep track of them. This would also imply that fork() is actually acceptable as long as the forked processes don't try to use the UI, but are merely background worker processes that communicate with the foreground process if they need UI interaction or etc.

FWIW, there is some special code in the main() program of kdeinit5 that
causes it to fork and re-exec *itself* on Apple OS X (the second time with a
--no-fork arg) --- before it goes on to do its main work.

For more detail, in frameworks/kinit/src/kdeinit/kinit.cpp code, see lines
1705 and 1576ff.  The comments at the head of the second reference say:

/**
 Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has always had issues
 on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
 result, in the case where we would normally fork and then dlopen code, or continue
 to run other code, we must now fork-and-exec.

 See "CoreFoundation and fork()" at http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html
*/

When I can get Qt 5 to build and then Frameworks and some KF5 apps, I propose
to start tracking down what is happening on Apple OS X in some of the paths that
kdeinit5 and friends are following, starting with what KToolInvocation is doing in a
few major cases.

For a rough but obviously now-out-of-date guide see:
https://techbase.kde.org/Development/Architecture/KDE4/Starting_Other_Programs

Cheers, Ian W.