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

[René J.V. Bertin]

> 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 ;)
> 
> René J.V. Bertin wrote:
>     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??

Cf. my https://git.reviewboard.kde.org/r/127649/ . Not sure what would be the leanest and most readable: turning the option on by default or using the inverse logic (= via an intermediate variable that will avoid the need for plenty of `NOT BUILD_APPLE_APPBUNDLE` statements). I guess time and practice will tell.


- 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/79378eee/attachment.html>