Hi,

As some of you may have picked up from my posts on other KDE MLs, I've been 
working to bring "KF5" to MacPorts via a set of ports that continue the 
tradition started with the KDE4 ports, and that correspond to MacPorts' 
approach. Everything is built as much as possible the way it is on Linux, to 
ensure the largest possible feature set, including an adapted KDE platform 
theme plugin allowing central selection of an application style, etc.

Overall this works fine but there are a select few exceptions that require 
extensive patching to the build system because the devs have made the 
assumption that builds on Mac are always supposed to lead to standalone app 
bundles. To be clear: most apps with a GUI should indeed live in an app bundle, 
that bundle need not contain more than the bundle exec, an Info.plist and the 
app icon. All the rest can be in traditional locations under a shared prefix 
(/opt/local by default in MacPorts).

It turn out that Krita is one of those select fews. I haven't followed the 
split-off closely so I don't know if this ML is still the best place to raise 
questions about building on Mac, but I hope I can still reach at least some 
Krita devs here.

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?

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
- seems to try to bypass QStandardPaths by setting up an XDG_DATA_DIRS env. 
variable

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é

Reply via email to