Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming

[Pete Batard]

Getting into the final pieces of the puzzle now, with 4 more commits in 
integration2.

The first one is yet another round of paranoia/unconfig removal (will we 
ever see the end of those?).

Second mostly adds a statically linked version of the extract sample for 
MSVC. Besides the actual MSVC project files, we also add a number of 
includes in the MSVC/missing/ directories (all of which are public 
domain) to compensate for files that vanilla Visual Studio versions 
would not have.

We also modify the win32 cdrom driver files so that
1. It works with Visual Studio
2. It doesn't require end user applications to link with any additional 
libraries beside the libcdio ones

This static version of the extract sample has the libcdio library broken 
down in individual driver, udf and iso9660 components, which may come 
handy for people who for instance just want ISO9660 support and don't 
care about UDF, etc.

The one thing that may require some afterthought is the fact that we now 
need to maintain a version.h in include/cdio/, since MSVC cannot 
autogenerate one from the .in. having both a version.h and vesion.h.in 
is not much of an issue for existing environments, since the existing .h 
will always be overwritten, but most crucial is the fact that the 
version.h currently needs to be updated manually for MSVC to reflect the 
current version, and whether git or an actual released was used.
I'm afraid there's no elegant way to solve the issue of supporting 
platforms that don't have autotools, so I'll let you decide what you 
want to do here. My thinking right now is that if changes of version are 
infrequent, manual editing of both configure.ac and version.h should be 
fine.


Now, the third commit adds a dynamically linked version of the cd-info 
sample (since this is the one that the XBox people had obsolete project 
files for) as well as a libcdio.dll. We also add a libcdio.rc so that 
one gets the version, licensing information and other information when 
checking the DLL properties.
In order for the DLL to have as low an impact as possible, and 
considering that we have to export the public function calls one way or 
another, I used a separate libcdio.def file. However, this only works 
well for exported function calls, but not for global library variables, 
and these require a __declspec(dllexport) prefix when building the DLL, 
and the __declspec(dllimport) prefix for DLL based libcdio applications.
As such, a few headers had to be modified to add a LIBCDIO_DLL_DECLSPEC 
prefix for global variables. Obviously, LIBCDIO_DLL_DECLSPEC is not 
defined to anything on anything but MSVC, and even then, only when the 
macro LICDIO_DLL is defined to indicate DLL usage, which any MSVC that 
wants to link against the libcdio DLL will need to define.
The LIBCDIO_DLL_DECLSPEC macro definition itself is done in types.h.

With these changes, I was able to get a dynamically linked cd-info 
executable from MSVC, that produces the expected results, including 
CD-Text and ISRC retrieval, so I think we should be in good shape as far 
as MSVC is concerned now.

The fourth commit is just a couple of deletion that were meant to occur 
in the third but that I forgot.

Once these commits are in, the -pbatard branch should pretty much become 
obsolete and any further patches from me will be submitted against master.

Regards,

/Pete