Dulwich C extensions and stand-alone Windows installation of bzr

[Vincent Ladeuil]

>>>>> Eli Zaretskii <eliz at gnu.org> writes:

    >> From: Martin Pool <mbp at canonical.com>
    >> Date: Mon, 12 Sep 2011 12:54:09 +1000
    >> Cc: John Meinel <john at arbash-meinel.com>, bazaar at lists.canonical.com, stephen at xemacs.org
    >> 
    >> What actually goes wrong when you try to make a DLL in the 'normal'
    >> way?

    > I didn't try because I don't know how to do that in this specific
    > case: what compiler switches to use, which libraries to link against,
    > and (last, but not least) where to place the resulting DLL.

Which should be described in  distutils.py, that's the point !

    > There isn't a word about that in the dulwich distro, only a
    > Makefile where I found that it invokes setup.py,

That's the standard way to do it to let python invoke the right
compiler/linker depending on the platform,

    > which in turn invokes some magic in a Python module I don't have
    > (distutils).

/me blinks

That's the bug. I thought distutils was part of the standard python
distribution. If you don't have this file, I should be wrong. Still,
there should be an easy way to install it ('easy_install distutils' ?)

    > If someone could run this on Unix or GNU system and tell me what was
    > the GCC command line run by setup.py, that would be a huge step
    > forward.

No, it will only tell you what runs on a GNU system, not what you need
to run on windows, but anyway, running 'python setup.py build_ext -i -v'
in bzr trunk:

running build_ext
building 'bzrlib._annotator_pyx' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/bzrlib
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_annotator_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o

... etc

Hth,

        Vincent