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

[Pete Batard]

On 2012.03.12 02:08, Rocky Bernstein wrote:
> A lot of the concerns you have seem to be for people writing applications
> (as opposed to end users).

Indeed. This is because those are compilation concerns, and I don't 
exactly see how they relate to end-users. Some aspects of libcdio impact 
end-users, other impact apps developers (and some both). When talking 
about pure compilation matters, end users are not really something we 
need to consider.

> Specifically those that use libcdio via MSVC and
> MinGW. So although we want to address this concern, it strikes me as a
> concern of very few people.

I'm not sure we can say that trying to help developers with the most 
widely used developer environments on the most widely used OS is a 
secondary concern, because their numbers are expected to be small.

Instead, if people are interested in libcdio on Windows, now that both 
MSVC and MinGW are supported, I see a good chance that these "very few 
people" may turn out not to be that small. From sheer market penetration 
figures alone, their number could actually end up being larger than any 
other group.

> Linking using -llcdio versus -winmm -lcdio is apparently important to you.
> On platforms other than MSVC and MinGW, one typically uses pkg-config and
> that gives what libraries and options to use.  Although I think it pretty
> rare that someone would have to issue a link command by hand as opposed to
> through some sort of build system, since this is of importance to you and
> you are willing to do the work, I'd say let's go for it. But yes, I'd still
> like the boilerplate stuff split out separately in the
> lib/drivers/MSWindows directory. We'll make sure to add comments about why
> the added complexity.

OK. If you're really adverse to it, I don't mind removing the code and 
go with -lwinmm. But indeed, MSVC users cannot use pkg-config (and 
pkg-config is also not available by default in MinGW/msys - it needs to 
installed separately), so I do see benefits in removing the need to link 
to a library, when it's just used for a couple of calls.

> I think it okay (if not complicating things more)  to put platform
> information another in header so version.h can be constant across all
> platforms and distributed in the tarball. But so as to reduce changes to
> source code, version.h should #include platform.h

Yes, that's how I see it as well. While I think version and platform 
should be split, I also want to make sure that we don't break existing code.

> On MSVC you should create
> platform.h as that will not be distributed in a tarball.

Actually, the way I see it, a platform.h would exist in the MSVC dir 
(but not in include) and will need to be distributed in the tarballs.
Unless you want to compute the actual bitness of the machine that 
compiled the library (which doesn't make much sense), rather than the 
bitness of the library itself, which can easily be deduced by looking at 
a macro, there's no point generating a platform.h on the fly in MSVC. 
Instead, it would take the form of a platform.h that contains something 
like:

#ifdef _WIN64
#define LIBCDIO_PLATFORM "x86_64_MSVC"
#else
#define LIBCDIO_PLATFORM "x86_32_MSVC"
#endif

Before I start to work on a proposal for version.h/platform.h, do you 
still want to have a version.h.in in the git repo (in which case we'll 
need both a version.h and version.h.in in git, because of MSVC), or do 
you want to go with a single version.h that gets updated from a script, 
along with configure.ac?
Of course there will be a platform.h.in in the includes directory.

While either way should be OK, I think version.h.in + version.h is 
probably preferable, since, unless you don't test the git repo after 
updating the version in configure.ac, the version.h would be updated to 
latest without needing to be manually edited.

Also, with regards to git versioning and the ability to get some 
indication of which commit was the latest when the library was 
generated, while it is of course not possible to use the actual commit 
hash in the files committed, the distance to the origin can instead be 
inserted automatically into a version file, by using a git pre-commit hook.
I tend to use this as the nano for software I release, as, outside of 
user modifications, it provides a fairly efficient way to identify 
precisely which was the latest commit in the repo the software was built 
from.
For instance, the current distance to origin for master in libcdio is 
2798. If you think there exists a need to be able to differentiate 2 
libcdio libraries by their commits, I can also try to work something out 
there.

> Thanks for trying the test with the #include cdio/disc.h and cdio/mswin.h.
> Given the problems, I guess adding LIBCDIO_DLL_DECLSPEC is the best of the
> bad possibilities. I'd ask however to put that on a separate line. To my
> aesthetics, this is better. For example:
>
>      LIBCDIO_DLL_DECLSPEC
>      extern const char *discmode2str[];

No problem. I hesitated about doing it like that in the first place.

> As for getters and setters, it looks like there is already a bit to do for
> another release. So best to put that off for now.

OK.

Regards,

/Pete