On 2012.02.14 01:41, Rocky Bernstein wrote:
> I will merge the various pbatard patches into master and write additional
> tests as I can.
Thanks. I do appreciate that and I'll see what I can do to help, at
least to make sure that any additional tests are validated against MinGW.
> So there is no confusion: merges and commits should preserve the property
> that "make check" and "make distcheck" do not fail. If these had failed in
> the past, that was a bug and should be brought to my or everyone's
OK. I haven't tried make distcheck - I only tried make check/test, so
I'll try to give it a go as well.
I'm afraid there are quite a few things to fix then, besides the .cue
which you already picked:
- 'make test' without first issuing 'make' fails on the UDF check (on
all platforms), because it cannot build extract. The reason is that gcc
is invoked without -DHAVE_CONFIG_H then. I spent some time looking into
autotools options to identify where the problem lies, but I haven't been
able to figure it out
- The locale command in check_common_fn.in is problematic: I found that
quite a few Linux platforms will return more than one en_US locale. For
instance, a CentOS platform I have access to will return: en_US,
en_US.iso88591, en_US.iso885915, en_US.utf8. Also some platforms don't
have a locale command at all. My suggested fix is in:
http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=commitdiff;h=06485701fbfeca65dc34dd2f5af1624702d883b0 - On Windows platforms, cd-info may have a .exe extension, which will
make the check_legal test fail. The check_legal.regex file needs to be
modified to accept a potential extension. Proposed fix is also with the
- The cd-paranoia-log.right must have line endings that are LF always
for the test to validate (even if you produce the log on Windows, as it
also appears to be produced using LF, even in text mode). If you use git
on Windows, with the autocrlf option, you will get a
cd-paranoia-log.right with CRLF thus the test will fail. A .gitattribute
needs to be added in /test to specify eol=lf. This can be found at the
NB: I am aware that the gitattribute and extract.c source have been
committed with CRLF terminators (which I still can't fathom, as I'm
using autocrlf with git, and I haven't had such an issue with other git
projects I push to). I'll fix that in the -pbatard branch and try to
make sure the commits in integration don't have line ending issues
> It is possible over time we may decide that the incompatibility introduced
> is large enough to make another branch for people to try out temporarily
> for testing.
> I don't have a time estimate on this other than before the next release.
That's fine. The code from libcdio-pbatard works fine with my app, so it
doesn't matter how long it takes for mainline to bridge the gap, as long
as these changes get integrated eventually.