On Fri, Feb 10, 2012 at 2:34 PM, Pete Batard <[email protected]> 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.
