cmake for dbus-python and dbus-glib

[Simon McVittie]

On 28/06/12 08:30, Christoph Höger wrote:
> Am 27.06.2012 20:06, schrieb Mark Mikofski:
>> Has there been any interest in cmake for dbus-python and dbus-glib?
>> I think it might make the build process easier for windows
>> environments (and msvc).

If you're patching the source code for Windows compatibility, please
attach those patches to a bug report in freedesktop.org Bugzilla instead
of maintaining a long-term fork - I'm happy to review portability patches.

If possible, I would prefer to avoid having two parallel build systems.
We have that in dbus, and it's a pain - everything that touches the
build system (e.g. adding new files) has to be done twice.

In principle it should be possible to compile dbus-glib and dbus-python
for Windows with the mingw or mingw-w64 toolchains - I haven't tried it
myself, but it certainly works for dbus. I believe binaries produced by
these toolchains should be compatible between mingw and MSVC, as long as
their APIs don't contain FILE* (which neither project does).

Having said that, having a reviewed parallel build system that is
in-tree is much better than everyone using an unreviewed parallel build
system from some other git repository - so if the mingw approach is
impossible, please send patches to the bug tracking system and I'll have
a look.

Please be aware that I do not consider dbus-glib to be a high-quality
D-Bus binding - I only contribute to it because Telepathy is
sufficiently entangled with it that it's going to take us a significant
time to port away. New GLib-based code should use GDBus, and existing
dbus-glib-based projects should be considering their exit strategy.

dbus-python is not ideal either (see its README), but it does at least
make more sense than dbus-glib.

    S