<html>
<head>
<meta content="text/html; charset=ISO-8859-6"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Am 25.10.2011 20:18, schrieb Alexander Neundorf:
<blockquote cite="mid:201110252018.11077.neundorf@kde.org"
type="cite">
<pre wrap="">On Tuesday 25 October 2011, Ralf Habacker wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am 24.10.2011 21:33, schrieb Alexander Neundorf:
</pre>
<blockquote type="cite">
<pre wrap="">On Tuesday 18 October 2011, Ralf Habacker wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
with the recent kde-runtime (and other) buildsystems there are problems
installing dbus service files, which need to be fixed.
In
<a class="moz-txt-link-freetext" href="https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/m">https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/m</a>
ast er/entry/knotify/org.kde.knotify.service.cmake there is
CMAKE_INSTALL_PREFIX/bin prefix used, which do not work in windows
enviroment, where the build install root is not equal to the client
install root.
</pre>
</blockquote>
<pre wrap="">
So the problem is that CMAKE_INSTALL_PREFIX is not necessarily used at
install time ?
</pre>
</blockquote>
<pre wrap="">
yes
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">On recent windows builds dbus services executables are installed in the
same location as dbus-daemon and other executables, so a './' prefix
should work.
Are there any objections to add an additional KDE_... DIR variable in
KDE4Internal.cmake for this, something like
KDE4_DBUS_SERVICE_BIN_DIR - the directory where dbus services
are installed which could be used in the service files.
which has to be set to
if (WIN32)
set (KDE_DBUS_SERVICE_BIN_DIR .)
else(WIN32)
set (KDE_DBUS_SERVICE_BIN_DIR ${CMAKE_INSTALL_PREFIX}/bin)
endif(WIN32)
and to use in service files like shown below:
*[D-BUS Service]
Name=org.kde.knotify
Exec=@*KDE4_DBUS_SERVICE_BIN_DIR@/*knotify4
</pre>
</blockquote>
<pre wrap="">
Don't know.
So the problem is that under UNIX we need the full path there, while
under Windows we would need the full path at install time there, which
is unknown at package-generation time.
</pre>
</blockquote>
<pre wrap="">
the best solution would be to use a relative path to avoid path
relocations on install time.
Install location for windows are currently all relative to install root.
</pre>
</blockquote>
<pre wrap="">
Yes, I know, and I think we should try to do the same under Linux/UNIX with
the KDE frameworks stuff.</pre>
</blockquote>
technical this depends on how the dbus activation code is
implemented. The unix implementation uses fork and the windows
implementation uses CreateProcess. Both shows different behavior as
mentioned below. <br>
<blockquote cite="mid:201110252018.11077.neundorf@kde.org"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">from kde4internal.cmake
...
if (WIN32)
# use relative install prefix to avoid hardcoded install paths in
cmake_install.cmake files
</pre>
<blockquote type="cite">
<pre wrap="">And under Windows org.kde.knotify.service.cmake is installed into the
bin/ directory ?
</pre>
</blockquote>
<pre wrap="">
no, the executable referenced by this service is stalled in the bin dir
</pre>
</blockquote>
<pre wrap="">
So, the ./ is because the bin-dir is in the PATH ?</pre>
</blockquote>
The above mentioned ./ has been found to work not in all cases and
in the meantime there are hints from Patrick von Reth to use only
the basic executable filename. This requires further investigations
to find out or define how to do.<br>
<br>
The important question here is: Are all kde provided dbus services
installed <br>
<br>
A. in the normal bin dir or <br>
B. in other locations <br>
<br>
As mentioned above the windows implementation of dbus uses
CreateProcess
<a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx</a>
to start the service. <br>
<br>
In case no prefix is used the following path rules are used: <br>
<ol>
<li>The directory from which the application loaded.</li>
<li>The current directory for the parent process.</li>
<li>The 32-bit Windows system directory. Use the <a
href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms724373%28v=vs.85%29.aspx"><strong
xmlns="http://www.w3.org/1999/xhtml">GetSystemDirectory</strong></a>
function to get the path of this directory.</li>
<li> The 16-bit Windows system directory. There is no function
that obtains the path of this directory, but it is searched. The
name of this directory is System.</li>
<li>The Windows directory. Use the <a
href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms724454%28v=vs.85%29.aspx"><strong
xmlns="http://www.w3.org/1999/xhtml">GetWindowsDirectory</strong></a>
function to get the path of this directory.</li>
<li>The directories that are listed in the PATH environment
variable. Note that this function does not search the
per-application path specified by the <strong>App Paths</strong>
registry key. To include this per-application path in the search
sequence, use the <a
href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx"><strong
xmlns="http://www.w3.org/1999/xhtml">ShellExecute</strong></a>
function.</li>
</ol>
According to this case and point A using the service name without
prefix will work, if there are point B case, we have to inspect.<br>
<br>
The unix implementation uses fork/exec, for which i do not know the
used search path rules<br>
<pre wrap="">
>Or, in other words, if it's not an absolute path, then to which dir is it
>relative ?
see above
</pre>
<br>
Ralf <br>
<br>
<blockquote cite="mid:201110252018.11077.neundorf@kde.org"
type="cite">
<pre wrap="">
Alex
</pre>
</blockquote>
<br>
</body>
</html>