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

[René J.V. Bertin]

I'm not arrogant enough to paraphrase something written below and say that any work to make autonomous app bundles possible is useless to me, but it is of no interest to me at this point.
I think I've made it clear abundantly that I'm only interested currently to start trying to get things to work on OS X. Once one can fetch the code, call cmake followed by make and end up with functioning libraries and applications we can start wondering how this can be made to satisfy the needs of everyone. 

So can we *please* get to the question now? Please start another thread if you want to discuss an official KF5/Mac approach.

Boudewijn Rempt wrote:

> Well, that's simple. As on Windows, applications on OSX shouldn't use
> those things. It is vanishingly unlikely that dbus is necessary for

That's easy to say for someone who has motivation to do things the official way on OS X (but for some reason not to simply make things easy and rewrite in ObjC...). But you cannot dictate and impose that on everyone.
So while I have no objection to making it possible to do things that way, the statement should read
"should be able not to use those things" rather than "shouldn't use those things".

Unless you're prepared to write backends that make this point transparent.

I sincerely hope that Baloo's decision to drop support for non-Linux systems without first setting up the framework to allow for backends that hook into platform search APIs through its own widely used API is not a sign on the wall for how it's going to be.
Very few Mac developers will be interested in hacking a huge set of foreign frameworks to use native technology, esp. not if the lack of reaction to previous calls for from "core KDE developers" is any indication.

As to DBus: support is provided through Qt, and they see enough reason to spend effort on that despite possible App Store issues.

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

Oh, so how does kmail get its mail?

> 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

You're welcome to do everything yourself of course ... I also recall that previous efforts of mine to bring Calligra to MacPorts were appreciated (and I don't think it's available in any other form, at least not until recently).
In the meantime, that "useless" MacPorts provides the binaries used to build Qt's own installers against, and it (and "colleagues") provide ample documentation and support allowing even relative n00bs to install, say, KDE PIM without significant hassle. I haven't tried Fink for a while, but MacPorts installs the applications under the official /Applications directory, where they can be found as clickable icons.

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

With all due respect, it's that kind of statement that is madless and gets us nowhere. And if the installed disk space footprint of v 2.9 is any indication,  multiplying that by N times all the dependencies would be foolish indeed in my book.

> 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).

I fail to see why on earth would anyone want to publish *free* software through the Mac App Store who doesn't also have paid software on there. It is nowhere near the sole source for OS X software. The (iOS) App Store is another thing, just like iOS is a whole different beast than OS X.
Also, as I said before, there is nothing on OS X that prevents you from providing shared resources in designated locations like /Library/Frameworks for shared libraries, /Library/Application\ Support instead of /usr/share, ~/Library/Application\ Support instead of ~/.kde/share/apps and ~/Library/Preferences instead of ~/.kde/share/config . It is even quite usual that things get installed there (in the system locations) without a dedicated installer (= at first startup).