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.14 10:30, Rocky Bernstein wrote:
> 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!

Will do.

> Yes version.h.in. But I was not considering adding version.h in git.

Well, to be blunt, not adding version.h in git would suck.

This is because it means we have to create some kind of parser (or 
provide a sed.exe binary in the git repo) in a pre-build process for 
MSVC that duplicates what autotools does, and creates a version.h from 
version.h.in + configure.ac.
Can be done of course, but it adds a lot of complexity and potential for 
breakage, all for the sake of avoiding having to commit a version.h in 
git...

Since I do not know of evidence where autotools would fail to overwrite 
a version.h from a version.h.in if one already exists (when picked from 
git the file would have write permission), and with the platform.h 
separated, I don't really much of a potential for issue here. If we go 
with a version.h in git, its version should always match the one from 
configure.ac and the only reason to have it manually edited would be if 
someone wants to tag their own custom version, for a libcdio derivative, 
which isn't something we need to concern ourselves with.

I apologize for being a pain here, but I am trying to look at the 
problem as objectively as I can, in terms of maintenance and stability, 
and from that perspective, committing both a version.h and version.h.in 
still makes a lot more sense to me than going with a version.h.in + MSVC 
workaround.

Outside of an autotools bug, the only problem we face is with the 
version in configure.ac and the one from version.h going out of sync. 
But since we've eliminated the case where people would edit a 
pre-existing version.h to do their own versioning as irrelevant, the 
only possibility left is with a maintainer changing the version in 
configure.ac but not running autotools afterwards to get version.h 
updated. This is a valid concern of course, so if you think it might 
happen, then I don't have a problem going through the whole MSVC 
version.h creation workaround. But if not, and I haven't overlooked 
something, I still see keeping both a version.h and version.h.in in git 
as the better logical approach.

> In tarballs though, there will be a version.h.

Yes. And that's also why I think it makes less sense. There will still 
be a version.h.in in the tarball and probably some people running 
autoconf rather than the provided configure => similar scenario to what 
we would encounter with version.h + version.h.in in git.

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

Agreed. But git alone cannot create a version.h from a version.h.in and 
configure.ac, and on Windows/MSVC, even with a development environment 
and git, you still wouldn't have a sed equivalent to use.

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

I don't see that as very reasonable either. The whole point of providing 
MSVC support is so that people can use a vanilla MSVC development 
environment, just like autotools+gcc (or configure+make+gcc) is another 
vanilla development environment.

Having to force users of the most common development environment of one 
OS, to install a non standard set of tools, just to have a couple of 
lines of header created for them doesn't strike me as something we want 
to make mandatory. If anything, better ask them to create the file 
manually, as it will both be a lot quicker and not require the download 
and configuration of something external, that they may be very 
unfamiliar with, and that they will probably ever only use for that task.

Regards,

/Pete