help linking to python for dbus-python bindings

[Simon McVittie]

On 05/07/12 06:08, Mark Mikofski wrote:
> *IT WORKS!*

Good to know. I've merged the wip-windows branch, so the next
dbus-python release will be similar to the snapshot you used.

Since you are now the world's foremost expert on compiling dbus-python
with mingw, would you mind writing a text file with instructions that
can go in the doc directory?

Instructions for compiling dbus-glib with mingw, or any patches you
needed to use, would also be very welcome.

> Also, I'm hopeful for the cmake build, because the win32 python is
> build on msvc90, and uses that redist for extensions, altho
> supposedly alt compilers can also be used (I've yet to test this -
> but I guess mingw-gcc-4.7  works!). Of course this will pose another
> issue for dbus-glib, which I haven't successfully built with msvc.

I believe mixing compilers is normally only a problem if you share FILE
objects across library boundaries (which dbus, dbus-glib and dbus-python
don't), or if you use C++ (which those projects don't). So, you should
be OK here.

> Question on merging the cmake branch - have Ralf Habacker's KDE patches
> [1] been merged?

If nobody has told the bug tracker about them, then most likely no.

> I guess maybe it would be nice to
> have all of the windows ports sync'd upstream (as was done for dbus) so
> there is a single source.

If people who have forked it want this to happen, the first step is to
put patches on the bug tracker for review. I do not periodically Google
for "dbus-python patch" or anything like that :-)

> Also, maybe I should have filed a bug, but I think it's an automake bug
> in python.m4 [2] not in dbus-python. The command that finds the python
> package directory, gets mangled on windows because it doesn't pad the
> backslashes with an extra backslash, so everything get run together,
> e.g. ${prefix}Libsite-packages, instead of
> ${prefix}\\Lib\\site-packages. My fix is to edit the configure file and
> add ".replace('\\\\\','/')" to those lines. Then it works on windows.

That might be a bug in Automake, yes. You should be able to work around
it by putting am_cv_python_pythondir on the configure command line,
something like:

    ./configure [... other stuff ...] \
        am_cv_python_pythondir='/opt/python/Lib/site-packages'

(If you set a *_cv_* variable - a "cached value" - like this, Autoconf
will trust what you say, and not do the automatic check it usually would.)

> Also, I am still getting the following warnings during make:
> 
>     libtool: link: warning: undefined symbols not allowed in
> i686-pc-mingw32 sharedlibraries

If it otherwise works, this warning is probably harmless. If there are
undefined symbols in the extension, I'd need to know which symbols they
are (preferably on a bug report).

    S