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

[René J.V. Bertin]

Albert Astals Cid wrote:


>> (just a non-default option). But it shouldn't be compulsory for everyone.
> 
> Why not?

Because it's an enormous lot of extra work that will lead to equally enormous 
disk overhead (duplicating everything for each and every application), as well 
as to applications that are cut off from each other.

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

This is nonsense. Applications in the App Store correspond to that stereotype, 
but outside of that store there is no such obligation.

> I'm not saying that a linux-like installation layout should be banned for KF5
> on Mac, but i think it should be non default, and the bundle solution should
> be default.

Applications will still be in bundles, but in the scheme I am pursuing (which is 
of the form that will be required for MacPorts, Fink, etc) those bundles will 
only contain application-specific resources. 

> Asking linux-like installation layout on Mac because it's what we use on Linux
> is similar to suggesting KF5 on Mac should use X11 because it's what we use on
> the Linux, and I hope we agree it's not a good idea.

That is besides the point, and you know it. Qt's QPA takes the rendering backend 
out of the equation (and the xcb plugin works almost perfectly on OS X).

> Again from my "I've used Mac OS X for like 2 months in my life" point of view,
> I think "KDE Frameworks" on Mac OS X should default to work on a bundle-like
> environment, if "KDE Applications" are not ready for it, adding a workaround
> at the application level may an acceptable way to bootstrap the applications
> running, but I don't think it should be the end goal.

First of, I think that this is something that has to be decided by Mac users. I 
think you might find that those who are interested in KDE applications either 
don't care about the issue (as long as those applications can be started through 
the Finder) OR actually prefer to have only a single, shared copy of the 
libraries and resources like icons. In any event that will be a requirement for 
distribution systems like MacPorts and Fink. Libraries can still be built as 
frameworks, though if the Mac community decides that the header files are to be 
part of those frameworks, ALL header #includes will have to be modified or made 
platform-dependent.
That's just one example of how invasive it would probably be to follow dogma and 
do things "the Mac way", and that's not mentioning the maintenance burden those 
changes will bring (with a majority of developers working on Linux with little 
to no affinity for those Macheads who cannot just do things like everyone else).

In any case, no matter what turns out to be feasible and is decided in the 
future, my question still stands: what would be the best way to add a .o (or 
alternatively a lib*.a) object to all link commands? I see this object as a part 
of Qt, it would make sense to link it in together with QtCore (which I presume 
is a dependency for just about everything KF5?).