1. 04 Oct, 2018 1 commit
  2. 20 Feb, 2018 2 commits
  3. 07 Feb, 2018 2 commits
  4. 24 Nov, 2017 1 commit
  5. 23 Oct, 2017 2 commits
  6. 18 Oct, 2017 3 commits
  7. 17 Oct, 2017 2 commits
  8. 29 Sep, 2017 2 commits
  9. 27 Sep, 2017 1 commit
  10. 25 Sep, 2017 1 commit
  11. 30 Jun, 2017 1 commit
    • Simon McVittie's avatar
      build: Introduce ${runstatedir} and use it for the pid file · 1477ca50
      Simon McVittie authored
      By default ${runstatedir} is the same as ${localstatedir}/run, but many
      Linux distributions configure it to be /run and mount a tmpfs in that
      location. All other factors being equal, it is preferable to use /run
      where available because it is guaranteed to be local, whereas traversing
      /var might involve automounting a networked filesystem (even though
      /var/run itself is very likely to be a tmpfs).
      
      /run or /var/run is currently only used in a few places in dbus, but
      I plan to make more use of it during the development of
      <https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
      
      The pid file is not part of the API between dbus and other software
      (other than distribution init scripts for dbus itself), so we do not
      need to keep it strictly compatible; so it is OK to move it.
      
      We do not yet use /run for the system bus socket, because that is
      part of the API between D-Bus clients and servers, and has always been
      "officially" /var/run/dbus/system_bus_socket.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
      possibility of changing that.
      
      Similarly, we do not replace /var/run/console with /run/console, because
      that path is part of the API between dbus-daemon and the obsolete PAM
      modules pam_console and pam_foreground that used /var/run/console.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
      future removal of that code path.
      
      In the CMake build system, the equivalent of ${runstatedir} remains
      hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
      the sort of system-wide installations that would consider redefining
      ${runstatedir} to /run, the Autotools build system is strongly
      recommended: in particular this is what Linux distributions are expected
      to use.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
      1477ca50
  12. 08 Jun, 2017 1 commit
  13. 18 Apr, 2017 1 commit
  14. 10 Apr, 2017 1 commit
  15. 20 Mar, 2017 2 commits
    • Ralf Habacker's avatar
      cmake, autotools: Add find package config support for cmake clients · d160c1a7
      Ralf Habacker authored
      With this support cmake and autotools generates cmake equivalent of
      pkgconfig files on configure time named DBus1Config*.cmake. These
      files are installed into the related directory where cmake expects
      find_package related config files.
      
      For instructions how to use this feature with clients see readme.cmake.
      
      With previous DBus versions each cmake client using DBus as dependency
      needed a related FindDBus*.cmake in its source distribution or in
      the cmake binary packages. With the 'config' find package style support
      provided by this patch this requirement has been removed.
      
      The generated config file uses pkgconfig on unix or autotools to
      fetch package build flags, which is the prefered way. On Windows
      we do not want to require CMake users to have pkg-config installed
      so it uses cmake buildin target export support for exporting all
      targets into DBus1ConfigTargets*.cmake.
      
      [smcv: make sure variable substitution works in Autotools too]
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721Reviewed-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      d160c1a7
    • Ralf Habacker's avatar
      cmake: Optionally create relocatable dbus-1.pc file · 21662782
      Ralf Habacker authored
      Relocatable pkgconfig files are necessary when using packages installed to
      a location that does not match the location for which they were compiled.
      
      However, using ${pcfiledir} is problematic for system installations
      in standard locations, because it interferes with pkg-config's
      ability to filter out -I, -L options that are redundant with compiler
      defaults (which is important if you are trying to use a newer version
      of a library than the system copy).
      
      In practice operating system vendors installing dbus to standard
      locations use Autotools, so we enable relocatable builds by default
      when building with CMake.
      
      For simplicity, we're also not relocatable if the library directory
      is something more complicated than lib or lib64 (e.g. under Debian
      multiarch); we don't want to have to compute how many ../ to add.
      This is non-trivial to determine in an Autotools build, so for now
      there is no support for relocation when built with Autotools,
      even as an opt-in feature.
      
      Going via the ${original_prefix} variable is because under Autotools,
      both ${prefix} and ${exec_prefix} technically default to NONE, with
      NONE replaced with their real defaults of /usr/local and '${prefix}'
      (respectively) later on. If we tried to expand ${prefix} at the time
      that we choose the value of ${pkgconfig_prefix}, that would cause
      a broken value "prefix=NONE" to be hard-coded.
      
      [smcv: no relocation on Autotools, make it optional in CMake,
      expand commit message]
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721Reviewed-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      21662782
  16. 14 Feb, 2017 1 commit
  17. 13 Feb, 2017 2 commits
  18. 10 Feb, 2017 4 commits
  19. 30 Jan, 2017 5 commits
  20. 13 Oct, 2016 2 commits
  21. 18 Aug, 2016 2 commits
  22. 16 Aug, 2016 1 commit