building kio on Mac

[Jeremy Whiting]

Alex's memory is correct. We can solve this in one of two ways:

1) Patching Qt's QStandardPaths, we tried that and it didn't seem to
get anywhere.
2) Using Qt's QstandardPaths when we build and install KDE software.
This is the approach I've taken locally and seems to work. I think
this is what is being done on the CI system also. The idea is to put
data files in either /Library/Application Support/foo or
$HOME/Library/Application Support/foo. Locally I'm using
/Users/jeremy/Library/Application Support by adding
-DKDE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support"

in the cmake-options in my .kdesrc-buildrc file.

One of the reasons I'm not installing into /Library/Application
Support is to not require sudo. I believe macports itself has policies
of not installing to either of these paths though, so it's not a
proper solution for macports I guess.

BR,
Jeremy


On Sat, Jun 6, 2015 at 10:15 AM, Allen Winter <winter at kde.org> wrote:
> On Saturday, June 06, 2015 10:41:48 AM Alex Merry wrote:
>> On Wednesday 27 May 2015 06:56:29 Allen Winter wrote:
>> > On Tuesday, May 26, 2015 09:12:13 AM Scarlett Clark wrote:
>> > > On Tuesday, May 26, 2015 12:06:22 PM Allen Winter wrote:
>> > > > % kdesrc-build kio
>> > > > Could not locate file "kf5/kdoctools/customization" in
>> > > > ("/Users/allenwinter/Library/Application Support", "/Library/Application
>> > > > Support") Could not locate file "kf5/kdoctools/customization" in
>> > > > ("/Users/allenwinter/Library/Application Support", "/Library/Application
>> > > > Support") Error: Could not find kdoctools catalogs
>> > > >
>> > > > kdesrc-build kdoctools succeeded though.
>> > > > I recall this was a QStandardPaths thing. but I forgot the trick to
>> > > > solving.
>> > > >
>> > > > help.
>> > >
>> > > -DCMAKE_INSTALL_BUNDLEDIR="{instPrefix}/Applications/KF5" -
>> > > DDATA_INSTALL_DIR="{instPrefix}/Library/Application Support"
>> >
>> > Why can't we put these settings in the top-level buildsystem?
>>
>> IIRC, there was some disagreement over the correct approach to take, both on
>> OSX and Windows (installing to the operating system's idea of where various
>> files should go vs patching Qt to allow for environment variables to put them
>> in other places). I think the outcome of that was that KDEers generally
>> preferred the patching Qt route, but Qt didn't want to take that upstream.
>>
> Too bad  Qt didn't want the upstream fix.
> And I suppose we aren't interesting in resurrecting KStandardDirs either.
> rock vs. hard-place. neither side will yield
>
>> Now, KDEInstallDirs currently sets KDE_INSTALL_BUNDLEDIR (which is the same as
>> CMAKE_INSTALL_BUNDLEDIR) to "/Applications/KDE", but sets KDE_INSTALL_DATADIR
>> (which is the same as DATA_INSTALL_DIR) to "${CMAKE_INSTALL_PREFIX}/share". We
>> could adjust those on OSX, but I don't know what would be the most useful
>> settings. does $prefix/Applications or $prefix/Library make sense if $prefix
>> is not / or $HOME? How do we deal with developers who just want to put
>> something locally in their home dir vs "proper" installations? I don't know a
>> whole lot about OSX software installation, so I'm not best placed to make
>> these decisions.
>>
> I recall we decided a while back that $HOME was not the right approach on OSX.
> I don't recall if the same was decided for Windows.
>
> jpwhiting: you had this all figured out, didn't you?