dbus service install on windows

[Ralf Habacker]

Am 25.10.2011 20:18, schrieb Alexander Neundorf:
> On Tuesday 25 October 2011, Ralf Habacker wrote:
>> Am 24.10.2011 21:33, schrieb Alexander Neundorf:
>>> On Tuesday 18 October 2011, Ralf Habacker wrote:
>>>> Hi all,
>>>>
>>>> with the recent kde-runtime (and other) buildsystems there are problems
>>>> installing dbus service files, which need to be fixed.
>>>>
>>>> In
>>>> https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/m
>>>> 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.
>>> So the problem is that CMAKE_INSTALL_PREFIX is not necessarily used at
>>> install time ?
>> yes
>>
>>>> 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
>>> 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.
>> 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.
> Yes, I know, and I think we should try to do the same under Linux/UNIX with
> the KDE frameworks stuff.
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.
>
>> from kde4internal.cmake
>> ...
>> if (WIN32)
>> # use relative install prefix to avoid hardcoded install paths in
>> cmake_install.cmake files
>>
>>> And under Windows org.kde.knotify.service.cmake is installed into the
>>> bin/ directory ?
>> no, the executable referenced by this service is stalled in the bin dir
> So, the ./ is because the bin-dir is in the PATH ?
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.

The important question here is: Are all kde provided dbus services 
installed

A. in the normal bin dir or
B. in other locations

As mentioned above the windows implementation of dbus uses CreateProcess 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx 
to start the service.

In case no prefix is used the following path rules are used:

 1. The directory from which the application loaded.
 2. The current directory for the parent process.
 3. The 32-bit Windows system directory. Use the *GetSystemDirectory*
    <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724373%28v=vs.85%29.aspx>
    function to get the path of this directory.
 4. 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.
 5. The Windows directory. Use the *GetWindowsDirectory*
    <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724454%28v=vs.85%29.aspx>
    function to get the path of this directory.
 6. The directories that are listed in the PATH environment variable.
    Note that this function does not search the per-application path
    specified by the *App Paths* registry key. To include this
    per-application path in the search sequence, use the *ShellExecute*
    <http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx>
    function.

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.

The unix implementation uses fork/exec, for which i do not know the used 
search path rules

>Or, in other words, if it's not an absolute path, then to which dir is it
>relative ?

see above


Ralf

>
> Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20111029/a5161b0c/attachment.html>