libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, hea


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
Date: Thu, 8 Mar 2012 21:09:57 -0500

On Tue, Mar 6, 2012 at 8:44 PM, Pete Batard <address@hidden> wrote:

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

Ok. Thanks for plugging away.

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

Ok. Will merge that when I get a chance.


>
> 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
>

I don't understand why this is a win in all cases. As you say in the
commit, this dynamically links with winmm.dll rather than linking against
winmm.lib. Isn't there an advantage to not having to rely on finding
winmm.dll at run time but instead have it statically linked into resulting
binaries? Also, there is a little bit of code bloat. The headers inside
MSVC/missing are fine, but the code inside win32 cdrom, especially
lib/driver/MSWindows/win32.c is now more complicated.

Given that you don't want to provide tests for the added complication, I
hesitate to complicate.


> 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.


Really? You can't run a program from MSVC that reads configure.ac and looks
for: define(RELEASE_NUM, xx),  define (CDIO_VERSION_STR,  yy) , changes $1
to xx in yy and then changes in  version.h.in @VERSION@ to xx and
@address@hidden MSVC? If that is too much work, another suggestion is given
below.


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.
>

I don't want to include version.h in include/cdio/version.h which can (and
mostly will be) wrong. Assuming it gets overwritten by autotools (except
when it doesn't) leads to confusion and errors.

For MSVC, one could store a version of version.h in that MSVC directory and
arrange the build system to move it to include/cdio/version.h before it is
needed. If this route is used rather than writing a program to create
version.h, updating version.h should be the task of those who build on MSVC
which is where the responsibility should lie.  And when that can't be done,
I'd rather leave it to the last known verified value. The fact that it
resides in MSVC rather than include/cdio will suggest that this is a
MSVC-specific concern.



>
>
> 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.
>

I looked too at this patch and it seems to spread MSVC ugliness around. Is
it possible in a header file inside the MSVC directory LIBCDIO_DDL_DECLSPEC
macro and the externs that need LIBCDIO_DLL_DECLSPEC? (And if this is done
perhaps you don't even need the macro. Then arrange for this header to be
included as the MSVC/config.h header is included?



> 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
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]