"non standalone app bundle" builds on Mac

[René J.V. Bertin]

On Sunday November 06 2016 14:21:00 Boudewijn Rempt wrote:

> I'm still here on this mailing list. To be frank, I don't really want a macports version of Krita: macports is fine and dandy for things that otherwise wouldn't be available, but in the case of Krita, it would only be yet another build with yet another set of bugs that I would need yet another system for to reproduce and try to fix. I don't want to support a macports version of Krita, and I wish I could be sure there wouldn't be one, so I don't have to ask every Apple user who accidentally uses the "macports" field instead of "app bundle" whether that's really what they're using.

Well, that's the point: it's NOT another build. It's a build that's just about exactly as it is on any other (BSD) Unix which doesn't use exactly the same libraries as Linux. Any bugs that occur as a direct result of building a different way would evidently be for us to fix, but it'd still be easier to determine responsibilities if we could agree at least on an official switch to turn from a supported to an unsupported build.


I'd go one step further and say that I'm not convinced that modifying the existing build system to generate a self-contained app bundle is the best way to go. What I've seen with Marble and now Krita looks brittle, (almost) hacks here and there where something needs to be done differently. In contrast, digiKam can also be built (and is distributed as) a self-contained app bundle, but there it's done much more like how Qt seems to suggest. Build normally, and then run an additional deployment step that bundles everything. Ditto for Kate and KDevelop: all 3 applications build in MacPorts as they do under Linux, with the only difference that GUI applications end up being app bundles that depend on stuff under ${prefix}.

I just checked, BKO doesn't have an "app bundle" field, not even for Krita bugs. 

Of course you can disgust us (me) enough that I just drop any efforts I might otherwise spend on the code, but in that case I also will not hide the reason why we're not providing a Krita port to anyone who requests one (and I have already had requests).

> Argh... Did they change that again? And, lovely, now that OSX is no longer called OSX, are they going to go back from Q_OS_OSX to Q_OS_MAC or Q_OS_MACOS?

Well good morning! ... This changed with Qt 5.0.0 . I don't know how they plan to follow Apple's own naming inconstancy, I guess we'll see when 6.0 comes out.

> That's needed to find the translations.

What's different with Krita translations that they cannot be found simply through QStandardPaths and the GenericDataLocation?


R.