building kio on Mac

[Ben Cooksley]

On Sat, Jun 6, 2015 at 9:41 PM, Alex Merry <alex.merry at kde.org> 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.

Just to clarify here: environment variables would never work for final
end user installations, so we need to be able to work with how the OS
likes to work for that.

Developer environments however are different, and was the use case we
were trying to resolve with the patches we sent in. The Qt developers
didn't want to provide any infrastructure at all to make developer
environments (including our CI system) easier. The maintainer(s) of
the QStandardPaths class never reviewed our patch, and the module
maintainer for QtCore wanted the opinion of a Digia employee who was
extremely unresponsive.

>
> 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.
>
> Alex

Regards,
Ben

> _______________________________________________
> Kde-buildsystem mailing list
> Kde-buildsystem at kde.org
> https://mail.kde.org/mailman/listinfo/kde-buildsystem
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem at kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem