Move DLLs to submodule

[mgeier]

This is an alternative to #116.

[bastibe]

This is a very nice solution!

It seems that there are more problem though (this applies to #116 as well):

Apparently, the __file__ in

_snd = _ffi.dlopen(_os.path.join(
_os.path.dirname(_os.path.abspath(__file__)),
'pysoundfile_data', _libname))

is resolved at wheel-build-time. When I import soundfile after renaming my pysoundfile_data directory, I get this error:

OSError: cannot load library /Users/bb/Projects/pysoundfile/pysoundfile_data/libsndfile.dylib: dlopen(/Users/bb/Projects/pysoundfile/pysoundfile_data/libsndfile.dylib, 2): image not found

Furthermore, if I don't rename the directory, I get this error:

OSError: cannot load library /Users/bb/Projects/pysoundfile/pysoundfile_data/libsndfile.dylib: dlopen(/Users/bb/Projects/pysoundfile/pysoundfile_data/libsndfile.dylib, 2): Library not loaded: /opt/local/lib/libogg.0.dylib
  Referenced from: /Users/bb/Projects/pysoundfile/pysoundfile_data/libsndfile.dylib
  Reason: image not found

I think I know the reason for the second point. The build script in https://github.com/bastibe/libsndfile-binaries still has a few issues. I'll correct that later today.

[mgeier]

Apparently, the __file__ in is resolved at wheel-build-time.

How could that possibly be the case?
The file soundfile.py is not executed at build time, it's only ever executed at import time.

When I import soundfile after renaming my pysoundfile_data directory ...

The error isn't surprising, but why would you want to rename the directory?

Furthermore, if I don't rename the directory, ...

Which should be the typical case ...

The dylib was indeed broken, as it still depended on another (libogg) dylib.
It's really annoying to compile something from static libraries if dynamic libraries are also installed in the standard library search path, since generally dynamic libraries are preferred.

Note to self: always check with otool -L libsndfile.dylib!

I changed https://github.com/bastibe/libsndfile-binaries a bit and I hope that fixes the issue.
Now I have to assume that no libogg.dylib is installed on the dylib build machine, I couldn't find a cleaner way (but for sure there is one).
For now it should work fine like this, for the future we can probably try something similar to the win32 method (compile a static libsndfile and then manually create libsndfile.dylib from all the static libraries without using libtool).
But right now I don't have time for that ...

[bastibe]

OK, seems to work now. My problems were due to a weirdly broken virtualenv.