[Top][All Lists]
[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: |
Pete Batard |
Subject: |
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming |
Date: |
Wed, 14 Mar 2012 13:19:25 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
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
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, (continued)
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/05
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/06
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/06
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/08
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/09
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/10
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/12
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming,
Pete Batard <=
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/18
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/19
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/20
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/20
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/05
- Prev by Date:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Next by Date:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Previous by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Next by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Index(es):