[OS X] adding a link module to all KF5 targets

[Boudewijn Rempt]

On Wed, 23 Sep 2015, Nicolás Alvarez wrote:

> 2015-09-22 19:28 GMT-03:00 Albert Astals Cid <aacid at kde.org>:
>> El Dimarts, 22 de setembre de 2015, a les 23:04:22, René J.V. Bertin va
>> escriure:
>>> On Tuesday September 22 2015 22:35:40 Albert Astals Cid wrote:
>>> > Shouldn't KF5 work with those sandboxing? I'd expect that KF5 goal is that
>>> > you can use it in applications that end up in the App Store.
>>>
>>> It might be possible that someone will someday write an application that
>>> uses (a) KF5 framework(s) and that might be suitable for the App Store if
>>> it conforms to all the rules. I strongly doubt that current KDE/KF5
>>> applications (Kate, KDevelop, KDE PIM apps, you name it) will be able to
>>> conform, with all the interdependencies on helpers, agents and what not.
>>> The only way I can see to comply with those rules is if each application
>>> has the full set of its link and runtime dependencies installed in a prefix
>>> somewhere in the app bundle (using relative paths because app bundles are
>>> supposed to work regardless of their install location). If someone wants to
>>> jump through all those hoops (and pay Apple 99$/year plus 30% of sales)
>>> that's fine and I'm not proposing anything that would make it impossible
>>> (just a non-default option). But it shouldn't be compulsory for everyone.
>>
>> Why not?
>>
>> As far as i know it's how mac apps work, you download a bundle and it has
>> everything in it, anything else than that is not a "real mac app" (i've used
>> macs for like 2 months of my life so i may be wrong :D)
>
> I agree that we should support self-contained .app bundles for our
> applications, and maybe even AppStore-requirement-compatible bundles,
> but we're currently far from being able to do that. If there is no
> place to put binaries shared between all our apps, which app would
> ship the kioslaves, kded5, etc? How would we ship dbus? How can apps
> talk to each other via dbus if each app starts its own daemon?

Well, that's simple. As on Windows, applications on OSX shouldn't use
those things. It is vanishingly unlikely that dbus is necessary for
inter-application communication on OSX -- it's already really rare that
_applications_ need to talk to each other using dbus on any platform,
as opposed to desktop system components.

For me, as someone who is going to have to publish an application on OSX,
any work on macports, fink or whatever is useless. I need to be able
to make a bundle, that's it. And as on Windows, caches, daemons, ipc,
out-of-process kio slaves, all that is simply out of the question. One
bundle, one process, no external dependencies. Anything else leads
to madness.

On the other hand, I won't ever be able to publish Krita on the Mac App
store anyway, let alone the iOS app store (though Steam is a possibility).

Boudewijn