Re: [Libcdio-devel] [PATCH 0/5] Integration of libcdio-pbatard changes

[Rocky Bernstein]

On Fri, Feb 10, 2012 at 2:34 PM, Pete Batard <address@hidden> wrote:

> With libcdio-pbatard now complete in terms of fixes and features, I am in
> a position to push for the changes to be integrated into mainline at last.
>

Great!


>
> As previously indicated I have created a new pbatard-integration branch
> dedicated where I will push a few commits at a time, with a copy of those
> also being sent to the mailing list, and will wait for integration before
> pushing some more.
>

This is very kind and considerate.

>
> While I was at it, you will see that I added a MSVC project for
> cd-paranoia in -pbatard, mostly because I was observing a crash there
> during testing, that was a lot easier to troubleshoot using MSVC. I have
> also applied fixes for tests that I found problematic, so that they now all
> work properly, including with MinGW (the only one that fails on MinGW now
> is rock-ridge, which is purely due to symbolic links not being available
> for extracted data on Window).
>

I can try to address that.


>
> The way I'd like to proceed, which is also how I am planning to submit
> patches, is to have the configure.ac fixes and extract.c sample
> integrated first, since not having them will hinder testing, then get the
> cumbersome but minor stuff out of the way (source headers improvements),
> then ensure that we have a set of tests that work on all platforms (there
> are a few things to address there) before finally going to the main course
> with core file patches.
>
> The 5 patches from this first salvo should be fairly independent and will
> stop short of the testing fixes.
>

I will try to look at these this soon. Again, thanks.


>
> Regards,
>
> /Pete
>
> PS: On a side note I'm quite pleased to have stuck with libcdio in my app
> and not switch to using 7-zip or something else, as tests shown that my
> application is about twice as fast on UDF extraction as the competition
> [1]. Of course, this is in great part due to the default Windows buffering
> mechanisms, since I haven't optimized anything with regards to extraction,
> and everything is very much read one block at time, but it also indicates
> that the libcdio code is not slowing us down in any way. Good job!
>
> [1] http://rufus.akeo.ie/ -> "(1) Speed comparison between Rufus and
> other applications"
>

Pretty impressive.

I too am glad you stuck with libcdio; we get the benefit of your
improvements. Thanks again.