On Sun, 6 Nov 2016, René J.V. Bertin wrote:
> Just how (un)sympathetic an attitude can I expect towards the idea of doing a
> "linuxy" build on Mac? Would you consider patches that make this optional,
> IOW, that uncouple the build type from CMake's platform token ("APPLE") but
> put it under control of an option (e.g. "APPLE_STANDALONE_BUNDLE") which
> could perfectly well be ON by default? Would there motivation to help me find
> "obscure" locations in the source code where build type and install location
> assumptions are being made?
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.
> Concerning that last aspect, and re: Krita, I notice:
> - the code uses a legacy (but still working) Qt token (Q_OS_MAC) but also an
> obsolete token (Q_WS_MAC) which I thought is no longer defined
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?
> - seems to try to bypass QStandardPaths by setting up an XDG_DATA_DIRS env.
> variable
That's needed to find the translations.
> After a few hours of work I'm now at a point where Krita builds and doesn't
> immediately abort or exit with an error message (nb: qFatal() just provokes
> what looks like a crash on Mac with stock Qt; the error message is never
> shown). It crashes immediately though when I open the preferences (settings)
> dialog - which starts DrKonqi just as you'd expect it to. I haven't yet had
> the time to figure out the reason for this crash, but it's an example of the
> sort of issue I might be asking for guidance about.
>
> While I could work around the whole issue with a few patches to the build
> system and symlinks in the app bundle to emulate a standalone bundle, I'd
> prefer to do this properly. Once committed (in all senses of the term), that
> should be easier to maintain and feel less like an uphill battle.
>
> Thanks,
> René
>
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
