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

[Rocky Bernstein]

On Mon, Mar 12, 2012 at 8:14 AM, Pete Batard <address@hidden> wrote:

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


We've discussed this ad nuasium -- I'm not adverse to it, just did not see
as important as you do. But that's okay. If others had a view one way or
other there's been a chance to weigh in. So as things stand, it's fine to
go for this provided we encapsulate the winmm part separately in a file in
the MSWindows directory.  Thanks!


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

Yes version.h.in. But I was not considering adding version.h in git. It is
derived from version.h. In tarballs though, there will be a version.h.

There is a distinction between people who build from tarballs and people
who build from git sources. The people who build from git must have even
development tools around. If nothing else - git.  And another approach for
MSVC users who want to build from git would be to check git out in an
environment friendly to autotools and then build your own tarball ("make
dist").



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

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