fancycode / python-libevent Goto Github PK

F:\Python\LibEvent\fancycode-python-libevent-cd2c5c7>python setup.py build
running build
running build_py
running build_ext
building '_libevent' extension
F:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nologo /Ox /MD /W
3 /GS- /DNDEBUG -I.\libevent-2.0.13-stable\include -IC:\Python27\include -IC:\Py
thon27\PC /Tcsrc/_libevent.c /Fobuild\temp.win32-2.7\Release\src/_libevent.obj
_libevent.c
src/_libevent.c(59) : error C2198: 'evutil_socket_geterror' : too few arguments
for call
error: command '"F:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' fa
iled with exit status 2

On Mac OS X I could not get setup.py to work until changing it as follows.

I didn't have the confidence to post this as a pull request, as I haven't tested these on other systems than my own (Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64), and fear these changes may have broken the library in some way. So I'm putting this as an issue, as something to try on a Mac OS X system.

if os.name == 'posix':

    libpath = '.libs'
    if os.uname()[0] == 'Darwin':
        libpath = 'lib'

        # When installed with brew, the libraries are in for example:
        # /usr/local/Cellar/libevent/2.1.8/lib (note: NOT .libs)
    else:
        # Also no rt library available on Mac OS X

        # enable thread support
        libraries.append('rt')

    extra_link_args.extend([
        os.path.join(LIBEVENT_ROOT, libpath, 'libevent.a'),
        os.path.join(LIBEVENT_ROOT, libpath, 'libevent_pthreads.a'),
    ])
    libraries.append('pthread')

We have an Anaconda install and we need to install python-libevent. The setup.py checks for the existence of the LIBEVENT_ROOT environment variable. In the case of Anaconda this is e.g. <ANACONDA_ROOT>/pkgs/libevent-/. The actual libraries are in lib, but setup.py searches .libs.

One option would be to tweak the Anaconda install and create a symbolic link from lib to .libs, but this is not desirable, as we are automating an installation process that would requires unnecessary intervention with already bundled software.

Alternatively, setup.py could search both .libs and lib...

I would argue that setup.py could take a best effort approach in getting a workable python-libevent installed by searching for available libevent.a options. It could e.g. raise an error if there's an ambiguity, but if there's only one option, found e.g. by checking the LD path, it should continue.

Are there any other suggestions? It does not seem to be related to virtualenvs specifically, as I get the same error installing to the system Python.