Re: [KDE/Mac] building kio on Mac

[René J . V . Bertin]

On Sunday June 07 2015 22:20:49 Alex Merry wrote:

 I'm not sure that's possible, at least not in a way that doesn't risk 
 breaking 
 more than it fixes.

Well, as I hinted at earlier, one possibility would be to link in an additional 
module that just instantiates a dedicated class in a global variable that calls 
a QSP class function. As long as that module doesn't do anything else that 
could interfere with other stuff there should be little risk.

As long as this only has to be done on OS X we might be able to exploit the 
fact that there is basically only a single compiler that will be used.

 But it's worth investigating, at least - you're right that 
 it would make most sense to have the behaviour of QSP set based on the 
 installation type.

Ah, some agreement, that's an encouraging sign :)

R.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: 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 win...@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?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Ian Wadham]

On 08/06/2015, at 5:13 PM, David Faure wrote:
 On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
 The maintainer(s) of
 the QStandardPaths class never reviewed our patch
 
 That would be me, and since I don't know how things should work on OSX,

a)
https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html
and scroll down to A Few Important App Directories
b)
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html
c)
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW2

 I am 
 not in a good position to decide. On top of that I come from the KDE world, 
 so 
 I can't really force a KDE patch into Qt if it's a bit controversial.

I think Apple's design philosophy is quite different from the XDG/KDE's.  So
an attempt to map XDG directories onto equivalent Apple OS X dirs is bound
to strike difficulties.

Read what c) above says about iOS (Every App is an Island).  That is the O/S 
for
iPhones, iPads, etc.  In an ideal Apple world, every app would be completely
self-contained, apart from access to libraries and the system, and that is 
the way
OS X (on Mac computers) seems to be trending.

In OS X (but not iOS), '/Library/Application Support' is allowed for apps to
be able to share data files between *users* of apps, but the preferred place
for apps to keep data files is in the bundle 
(/Applications/.../appname.app/),
down in sub-directory Contents/Resources/.  In KDE 4 apps, I think only 
application
icons are placed there (by MacPorts), so that they can appear in the Dock (for 
quick
launches) or in displays of /Applications directories by the OS X file manager.

By contrast, XDG/KDE apps and libraries are sharing files between 
*applications*,
as well as users, often in an indirect way via libraries and background 
processes
(whether in KDE 4 or KF5).  Apple OS X developer documentation does not forbid
this, but I have not seen any place where it supports it and says how to 
achieve it.
Indeed Apple doco seems to gently discourage sharing between apps in some
places and I seem to remember some rumblings about security in that connection.

Apple OS X does not *prevent* using Application Support directories in any way
you like, but I think some kind of workaround in QSP is needed to keep KF5's
usage neat and tidy and maybe even under the radar.  Traditionally suppliers
of third party software have created their own subdirectories in Application
Support.  So my ~/Library/Application Support and /Library/Application 
Support
directories contain folders for Mozilla/ and Oracle/.  Apple itself would have 
subdirs
with the names of its apps (iPhoto/, iDVD/, etc.) and some suppliers of major 
products
would do that too (Gimp/, audacity/).

The more recent naming convention encouraged by Apple requires the supplier's
reverse domain name as a prefix, i.e. the name should include the app's name and
its source.  So I also have org.videolan.vlc/.  I do not know whether something 
like
kde.org/ would be OK, with subdirs like kde.org/share and kde.org/appname
(I hope that is correct: I am relying on memory), but it would avoid crowding 
the
Application Support directories with KF5 apps.

Another thing that keeps me awake at night (not really :-)) is an OS X daemon 
called
taskgated, which intercepts and security-checks process invocations.  See:
http://stackoverflow.com/questions/18423124/please-check-gdb-is-codesigned-see-taskgated8-how-to-get-gdb-installed-w
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/taskgated.8.html

At the moment, in MacPorts, taskgated is running in Tiger mode (i.e. as in OS 
X
about 10 years ago), which bypasses such checks.  But the day may come when
Apple decides to deprecate and discontinue the bypass option, in which case
software from the KDE Community will need to be codesigned on Apple OS X.

Well, I am not an expert on Apple software, but I hope this has been helpful.  
The
MacPorts group has greater experts, so perhaps one of them could help KF5 and
Qt 5 people further regarding Qt's QSP and KF5's (and KDE 4's) runtime tasks.

Cheers, Ian W.




___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [KDE/Mac] building kio on Mac

[Alex Merry]

On Sunday 07 June 2015 23:40:30 René J.V. Bertin wrote:
 On Sunday June 07 2015 22:20:49 Alex Merry wrote:
  I'm not sure that's possible, at least not in a way that doesn't risk
  breaking more than it fixes.
 
 Well, as I hinted at earlier, one possibility would be to link in an
 additional module that just instantiates a dedicated class in a global
 variable that calls a QSP class function. As long as that module doesn't do
 anything else that could interfere with other stuff there should be little
 risk.
 
 As long as this only has to be done on OS X we might be able to exploit the
 fact that there is basically only a single compiler that will be used.

The problem is that Jeremy's comment wasn't quite correct - KDEInstallDirs 
isn't a macro, and doesn't know anything about the targets that your project 
is building. It's just a module that provides a bunch of variables telling you 
where to install various types of files.

That said, if we implement a profile system, it would be easy enough to export 
a variable that tells you whether to link your Qt5-based programs against some 
extra library.

Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Ben Cooksley]

On Mon, Jun 8, 2015 at 7:13 PM, David Faure fa...@kde.org wrote:
 That wasn't very constructive/positive...

Sorry, i've spent way too much time fighting with the Qt folks on this one.


 On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
 The Qt developers
 didn't want to provide any infrastructure at all to make developer
 environments (including our CI system) easier.

 The *any* here is too broad. One approach was rejected, there are tons of
 others. E.g. just naming the variables QT_ instead of XDG_ might have been
 less controversial.

Thiago rejected that approach immediately when I suggested it over IRC.
He basically said it was XDG_* or nothing, and won't allow XDG_* to
proceed unless it is given the okay by the previously mentioned
unresponsive Digia employee.

As maintainer of QtCore he holds veto rights in this instance I believe.

 But since everyone was saying, at the same time, that end users don't want env
 vars, I can understand that the Qt developers thought this issue needs more
 thinking, to solve all uses cases, not just KDE CI (which was a too
 restrictive line of argumentation compared to what it really was, developer
 setup, as you say).

 The maintainer(s) of
 the QStandardPaths class never reviewed our patch

 That would be me, and since I don't know how things should work on OSX, I am
 not in a good position to decide. On top of that I come from the KDE world, so
 I can't really force a KDE patch into Qt if it's a bit controversial.

That makes sense.


 , and the module
 maintainer for QtCore wanted the opinion of a Digia employee who was
 extremely unresponsive.

 --
 David Faure, fa...@kde.org, http://www.davidfaure.fr
 Working on KDE Frameworks 5


Regards,
Ben
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[David Faure]

That wasn't very constructive/positive...

On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
 The Qt developers
 didn't want to provide any infrastructure at all to make developer
 environments (including our CI system) easier. 

The *any* here is too broad. One approach was rejected, there are tons of 
others. E.g. just naming the variables QT_ instead of XDG_ might have been 
less controversial.
But since everyone was saying, at the same time, that end users don't want env 
vars, I can understand that the Qt developers thought this issue needs more 
thinking, to solve all uses cases, not just KDE CI (which was a too 
restrictive line of argumentation compared to what it really was, developer 
setup, as you say).

 The maintainer(s) of
 the QStandardPaths class never reviewed our patch

That would be me, and since I don't know how things should work on OSX, I am 
not in a good position to decide. On top of that I come from the KDE world, so 
I can't really force a KDE patch into Qt if it's a bit controversial.

 , and the module
 maintainer for QtCore wanted the opinion of a Digia employee who was
 extremely unresponsive.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Ben Cooksley]

On Sat, Jun 6, 2015 at 9:41 PM, Alex Merry alex.me...@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@kde.org
 https://mail.kde.org/mailman/listinfo/kde-buildsystem
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: [KDE/Mac] building kio on Mac

[Alex Merry]

On Sunday 07 June 2015 19:24:16 René J.V. Bertin wrote:
 On Saturday June 06 2015 18:48:17 Jeremy Whiting wrote:
  KDEInstallDirs is just a cmake macro
 
 used at build time.
 
 That ought to be enough if it can be extended either to do something that
 can switch QSP behaviour. There's something to say not to make that a
 runtime switch: a priori it's something that should be set once, and
 preferably for every application that links to a given KF5 install.

I'm not sure that's possible, at least not in a way that doesn't risk breaking 
more than it fixes. But it's worth investigating, at least - you're right that 
it would make most sense to have the behaviour of QSP set based on the 
installation type.

Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Alex Merry]

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.

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
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Allen Winter]

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?
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Alex Merry]

On Saturday 06 June 2015 13:12:24 Jeremy Whiting wrote:
 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.

So it seems like we can't specify defaults that will satisfy even most people, 
let alone everyone. The best I can see us doing is implementing some sort of 
profile system in KDEInstallDirs that would switch the defaults wholesale by 
specifying a single argument. I don't know whether that would be worth it or 
not - depends how easy it is to implement and maintain, I guess.

Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Allen Winter]

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?


___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem

Re: building kio on Mac

[Allen Winter]

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?

___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem