On Tue, 2010-10-26 at 14:31 +0200, Michael Chinen wrote:
> I recently submitted a fix for bug 238 that patches libsndfile. They
> have committed the patch upstream. I haven't patched lib-src yet so
> please let me know how to proceed. Is it okay to just patch our
> lib-src and commit the patch with a note in patches.txt? Or do we do
> pulls on their trunk in the case of upstream acceptance?
It's a bit of a mess. Normally we only track upstream release versions,
so wouldn't pull until the next release is made. Unfortunately we are
now several releases behind upstream, as you will have noticed.
The reason for this is because we build libsndfile with Microsoft's
Visual Studio compiler, which upstream refuses to support (he insists
that using his cross-compiled win32 libs should be enough for anyone,
however the trail of unicode compatibility issues and the fudge function
in the API for the purpose suggests that it isn't). Win32 patches don't
get accepted upstream - I've tried. As a result after the release we are
currently using, Eric merged a bunch of changes which he saw as code
cleanup but which make the released sources very much harder to compile
with anything other than GCC. No-one has yet had the enthusiasm to
devise a means of making the current release sources compile (and pass
test suite) on Windows using Visual C++ that will be maintainable in the
future.
The options are roughly:
* Massive patch (probably touches most of the source files) which has to
be re-based at each release
* Fork Eric's bzr tree
(http://www.mega-nerd.com/libsndfile/development.html) and use that to
maintain a similar branch which does compile on windows (using bzr
allows pulling Eric's changes more often and less painfully, but I don't
know anything about bzr)
* Devise some sort of shim library which provides (or over-rides)
whichever functions aren't present / don't work in Visual Studio so that
the sources don't need to change but the resulting code works.
The last one could be done via either of the first two mechanisms to
make using the result easier. It may be worth contacting any other
projects which build libsndfile for Win32 to find out what they are
doing about this problem (fairly obviously, this would have to be done
other than via the libsndfile mailing lists).
Richard
|