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=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
In particular this makes them more MinGW-friendly: pkg-config on Windows
has specific code to rewrite the ${prefix} when installed in a
different prefix.
[add @datarootdir@, expand commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75858
When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.
Based on patches from 'william' on fd.o #46367.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33973
Tested-by: René Berber <Rene.Berber gmail com>
This does still need to be in configure.ac, because it's common to
dbus/Makefile.am (linking the static/shared library) and dbus-1*.pc.in
(telling static library users which additional libraries they must link).
"Private libraries are libraries which are not exposed through your
library, but are needed in the case of static linking" -- pkg-config(1)
Reviewed-by: Colin Walters <walters@verbum.org>
We already export the session services dir in the .pc file, add the
system services dir too, as well as the interfaces dir, so that packages
can drop their files into the right place.
Eventually we need to move the system-services dir to a place that is
relocatable to /lib/dbus, and this change makes the location queriable
for other projects, as a first step towards that goal.
- dbus/dbus-bus.c
(internal_bus_get): new method that take over the heavy lifting
of dbus_bus_get and adds the ability to get a private connection
to the bus
(dbus_bus_get): wrapper to internal_bus_get that provides the same
interface as in previous versions
(dbus_bus_get_private): new method that is a wrapper to
internal_bus_get to get a private connection to the bus
- dbus/dbus-bus.h
(dbus_bus_get_private): add as a public libdbus interface
- dbus-1.pc.in: output system_bus_default_address and
sysconfdir variables so apps can use them when compiling
* dbus-1.pc.in, dbus-glib-1.pc.in: rename these from
dbus-1.0.pc.in, dbus-glib-1.0.pc.in. As these change with the
parallel install API version, not with the D-BUS package version.
* HACKING: move some of README over here
* README: updates, and document API/ABI policy
* configure.in: reindentation
