Thoughts concerning (ease of) building on other supported platforms

[René J.V. Bertin]

Hello,

I got pulled into a discussion elsewhere, which led to a number of thoughts I thought I'd best share here in hope they'll lead to something constructive.

This mostly centres around building on platforms where it is less usual to install resources that can be shared (libraries, config/interface files etc) in such a way that they can indeed be shared among different applications, modules, kparts, etc. The main platforms concerned are of course OS X with its possibility to provide all-encompassing, standalone app bundles and MS Windows where each application tends to install all stuff it needs in its own directory. If you forget about a few sexy details, those 2 approaches are really almost identical. Both platforms also share the fact that QStandardPaths returns very different things.

The crux is in the "less usual". I hesitate even to use "not the preferred way" because there are sufficient exceptions - *in addition to* software distribution systems (with or without binary packages) that aim to provide an environment for FOSS/cross-platform software that's as close as possible to the principal universe in which that software evolved (i.e. Linux). To name but a few: Cygwin, HomeBrew, MacPorts, Fink, pkgsrc, Gentoo Prefix.

I'll be focusing mostly on OS X which is still my OS of choice, and MacPorts which is the distribution/packaging/build system I use to build, install, maintain (etc) software that isn't provided by Apple or linked to intricately to the system to meddle with. Since I also use Linux I vastly prefer software to function as much as possible the same way on both platforms, with as full a feature set as possible and things installed in locations that are as similar as possible. Example: I use Kontact/Kmail on both platforms; I have a hard time imagining bundling all of KDE PIM in a single app bundle (that'd be running its own private DBus daemon?) without losing crucial features or requiring significant hacking of the code.

Let me repeat something I've said before but that I think hasn't been picked up too well. OS X has various mechanisms for installing applications. The "drag-an-icon" metaphor is probably the most visible and interesting (to people who're used to other platforms and not actually OS X users themselves), it can be very convenient even to seasoned power users, etc. But it is just one of the ways an app can be installed. Apple's own applications do not use that approach by and large. Those that are not shipped through the App Store mostly use a traditional installer instead. It isn't particularly difficult to create packages for the Installer.app either - in fact, MacPorts command-line utility has a command to create a disk image (DMG) containing an installer for either a single package or for a package with all its dependencies.

Also, do not think that the standard, unpatched KDE build process leads to anything other than app bundles on OS X. It's the contrary, rather; you need to invoke (the inaptly named) ecm_mark_nongui_executable in order to build a target as a regular executable. It is true that the app bundles you get with the current build system are not standalone in the sense that they contain everything the application depends on except for the system libraries. But they behave exactly like standalone app bundles; with the only exception that's not possible is to copy them to and run them on a different host that doesn't have the dependencies installed where they're expected. But the same goes for many apps from Apple; if for some reason you uninstall iTunes from a Mac (or really bork the entire install), you cannot reinstall it simply by copying iTunes.app from another Mac.
That exception aside, unconcerned users really won't see the difference - and with an installer they don't even have to wonder where they're going to put an application. And to be honest, most really "n00b" users I've had to deal with actually have difficulties going beyond the download of a dmg. It's very common to come across systems that have numerous copies of those disk images, but that don't have the application installed because the user never caught on to how to proceed after the download.

Hopping back on my thought train, I'd even go so far to say that if you (in general, not limited to KDE) really care about user convenience in the context of distributed, free software development, you're going to aim for an approach in which it becomes both easier and more urgent to provide (or rather, support) up-to-date versions of the KF5 frameworks. When everything is bundled, it's easy to become sloppy and rebundle a new binary package only once in a while. If however you aim to provide the frameworks (and select other libraries) in a centralised fashion it becomes feasible to provide a (semi)automated updating mechanism, and all installed applications benefit from the latest bug and security fixes (and package maintainers gain an incentive to keep their packages up to date).

Question: don't frameworks like Sonnet have their own set of user-preferences which are supposed to apply to all applications using those frameworks? That would be impossible if you follow Apple's App Store guidelines for completely standalone appbundles.

All this to make a bit of a passionate request: whatever is decided for the "official" way to build things (on OS X), please consider the use case for a more traditional way of building and ensure that it remains possible to select that through a CMake option instead of through what would certainly become an intangible forest of patches. Also see Marko's reaction below.

In that context, it would probably be a very good idea to reimplement parts of the build system so that install locations are determined from the actual paths returned by QSP rather than more or less hardwired.

That should prevent a lot of platform-specific hacking in CMake files and make it a lot easier to maintain a system that can cater for both the "linuxy" install layout and a more platform-native way of installing things. I'm not very familiar with the K*5 build system intrinsics, but I reckon it sh/could involve calling a utility like qtpaths from a central ECM module
Ideally that would probably be a utility that gets built when installing ECM. As long as there's hope I'll continue to clamour for as official a solution as possible to chose between a "native" or a "linuxy" way of installing things, and that could well mean that that utility should be written from scratch (it could also be useful to pass in the install prefix).
In any event I think the build system and the runtime cannot but agree one where things are supposed to be found. Supporting an XDG-compliant ("linuxy") install layout will require patching QSP on platforms where this is necessary (an effort that won't have to be supported by KDE of course), so using QSP to determine install locations where possible would solve part of the problem of introducing platform-specific code in the CMake files.

I hope all this wasn't too vague ... and an open door for most ;)

Cheers,
René