Forking of libdvdread

Hello

I'm sad to have to hear about this.

Why do you feel it's necessary to fork this code?

From the cvs commit:
> Add files from libdvdread.
> This is to provide better integration with libdvdnav.
> Better error messages reported to the application etc.

What do you feel is missing?  Adding better return codes and a structured
error message system would be a good things in general and not just some
thing that only libdvdnav would benefit from.

> We will modify libdvdread files to be portable across all compilers.
> Currently, libdvdread only behaves with gcc.

It behaves with many versions of gcc and Suns Forte C compiler.  
These are the two compilers I have access to and care for.  

If you want to make it more portable be my guest, I'll take those
patches. No need to create a fork for that.  I just won't do this 
work my self because it already work on all platforms and compilers
I have tested with.

> libdvdread does not like Microsoft Compilers.

Yes, so why do you need to use them?  There are the mingwin and 
cygwin systems for Win32 platforms.  Granted I've not tested with 
them either.

> This portability modification will change libdvdread so much,
> that I thought it best to finally combine libdvdnav and libdvdread
> into one lib.

Why would it need to do that?
The types in ifo_types.h, nav_types.h would be simplified but not
necessary change names or even break source compatibly.
The functions in ifo_read.c and nav_read.c would have to be updated to
match the new types but that would practically be that.

> Currently the added files are not used.
> Future commits will change that.

-- 
Håkan Hjort