[KDE/Mac] [OS X] adding a link module to all KF5 targets
René J.V. Bertin
rjvbertin at gmail.com
Tue Sep 22 23:03:29 UTC 2015
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
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?).
More information about the kde-mac