[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: dbus service install on windows
From:       Ralf Habacker <ralf.habacker () googlemail ! com>
Date:       2011-10-29 7:01:44
Message-ID: 4EABA4D8.8070802 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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


[Attachment #5 (text/html)]

<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.as \
px">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="">
&gt;Or, in other words, if it's not an absolute path, then to which dir is it 
&gt;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>



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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic