Review Request 128202: Fix problem with install prefix & application bundles

Sat Jun 18 11:01:28 UTC 2016

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote:
> > AFAIK emerge is not an OS X utility, but something ported from elsewhere. Does it use `-DBUNDLE_INSTALL_DIR` and if not, why?
> > 
> > A few remarks re: kded5. AFAICT this is one of those things that should *not* be installed by each and every application somewhere in its appbundle. I don't think it'd work to run multiple instances of it?
> > As to finding it: there are 2 ways to address that particular issue. First, kded5 probably ought to be built as a non-app-bundle agent (https://git.reviewboard.kde.org/r/126170/ and the associated https://git.reviewboard.kde.org/r/126161/; kdeinit5/klauncher should probably also *not* be run independently by each and every standalone application that needs them?!).
> > 
> > The second approach concerns all services that are to be auto-started using `.desktop` files or equivalent: those files need to be rewritten so that their Exec key contains an appropriate value. In standalone app bundle builds this could of course also be handled by amending `PATH` as the very first thing when starting up, or even before that by using a wrapper script as the `BundleExec`.
> 
> Christoph Cullmann wrote:
>     For the bundle dir, see my response below, for kded5: actually, thou shall not use it on mac nor windows.
> 
> René J.V. Bertin wrote:
>     It's you who brought up kded5, and please know what you're talking about before making statements like that (better yet, do not make them at all unless they have a salient emoticon). There are things kded5 does that are going to be required on MS Windows and OS X too until they're migrated away from kded, like cookie management for instance. Maybe we shouldn't use sycoca5 on our platforms either, or any KDE application that depends on the Kded framework?
> 
> Christoph Cullmann wrote:
>     kded5 was just an example, I should pick my examples better it seems.
>     The same happens with other stuff that goes there.
>     And no, I keep my position: Thou shall not use kded5 on Windows nor Mac for ported stuff. And yes, that is work. But e.g. KDevelop, Kate, Krita, ... seem to work just fine without it beside some minor regressions.
> 
> David Faure wrote:
>     ksycoca doesn't require kded anymore, the functionality is entirely contained in the kservice module.
>     
>     kcookiejar is still a kded module but I plan to make it a kiod module. Not much difference though (apart from dependencies), it'd still require DBus. The current strategy seems to be that KIO is not really needed for Windows / OSX app bundles. I hope we can find solutions though, but it doesn't seem to be a priority.

If kded5 becomes unnecessary that's fine ... and statements like "thou shalt not use it" becomes the BS I already consider it to be and to which I'm so allergic.

> On June 18, 2016, 11:17 a.m., René J.V. Bertin wrote:
> > kde-modules/KDEInstallDirs.cmake, line 388
> > <https://git.reviewboard.kde.org/r/128202/diff/1/?file=468904#file468904line388>
> >
> >     Is this going to change anything when you define BUNDLE_INSTALL_DIR on the commandline?
> 
> Christoph Cullmann wrote:
>     emerge doesn't set BUNDLE_INSTALL_DIR and yes, if you set it, that will overwrite the dir computed, that is clear.
>     The question is, why bundle_dir is the only dir that doesn't honor: CMAKE_INSTALL_PREFIX like all other dirs.
>     I see no problem in letting it honor that to be able to locally install stuff if prefix is set.
> 
> René J.V. Bertin wrote:
>     I think you should begin by fixing your build script so that it uses the provided mechanism to initialise BUNDLE_DIR to exactly what you want it to be, and only patch ECM if that doesn't suffice.
>     Making the default path relative may work for you, but it will lead to surprise for others. I guess your use here is to let helper applications be installed automagically into the app bundle you're building. For that use case they do NOT have to be in a `/Applications/KDE` subdirectory. There doesn't appear to be an official Apple guideline on where they should be installed, but there seems to be a pattern of putting helper applications directly into Contents/Resources.
>     
>     As long as BUNDLE_INSTALL_DIR still overrides CMAKE_INSTALL_PREFIX there is no problem in initialising BUNDLE_DIR from CMAKE_INSTALL_PREFIX. The reason it is not is simple: the standard BUNDLE_DIR (/Applications) is not a subdirectory of the standard INSTALL_PREFIX for system software. Also, application bundles are NOT found via the standard Unix search path, whereas things installed into CMAKE_INSTALL_PREFIX are.
>     
>     This is a question you'd want to take up on the cmake ML, but I think that any answer you'll get will be of the type "works as intended".
> 
> David Faure wrote:
>     It seems to me that we might need an ECM setting to choose between two modes when building on Mac: the "self-contained app bundles" mode, where we try to put as much as possible into the bundle, and the "full install" which is more like the Linux setup (more shared stuff). You can then each maintain your own solution ;)

That would at least reassure me somewhat ...

But WTF gave the green light to commit this? What's the point in doing RRs if we're going to commit our proposals when there are open issues and no one gave a ship-it??

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128202/#review96661
-----------------------------------------------------------

On June 18, 2016, 12:38 p.m., Christoph Cullmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128202/
> -----------------------------------------------------------
> 
> (Updated June 18, 2016, 12:38 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, Alex Merry, and David Faure.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> -------
> 
> Current behavior: Even if you have some own installation prefix like emerge, ECM assumes all stuff in the global /Applications/KDE
> This doesn't work as stuff like kded5 is not found after installation.
> Making it relative resolves this issue.
> 
> 
> Diffs
> -----
> 
>   kde-modules/KDEInstallDirs.cmake f518a4a 
> 
> Diff: https://git.reviewboard.kde.org/r/128202/diff/
> 
> 
> Testing
> -------
> 
> emerge okular works a bit more with this patch, e.g. kde4support is able to detect kded5.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160618/2bda1754/attachment-0001.html>