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é
_______________________________________________
Kde-buildsystem mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-buildsystem
