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
