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

[Rocky Bernstein]

Again this is long. Originally I tried commenting in line, but the same
issues came up repeatedly. So, as before, I will not try to respond in
line. I think I've covered everything.

There is an assertion that if it were just that for one little file,
version.h, life would be so simple on MSVC in building from git. This may
be true, but only from a very limited point of view. And one I don't want
to promote.

First, there's the fact that git *itself* is an added tool. But if you want
to build manual pages for programs like cd-info, you will need "help2man";
for the documentation that can be read in Emacs, "makeinfo" is needed.  At
one point I considered redoing CUE parsing using "Bison'; there is a
project already that does this that we might use. It is also possible in
the future we will handle internationalization using "gettext".

So although if one looks at things only from the narrow view of developing
from git sources on MSVC as libcdio is today -- excluding documentation and
other niceties (or I would argue necessities) such as the ability to run
the built-in checks or PDF documentation -- then, yes, having to deal with
version.h is currently a problem. In addition to the automated ways
previously in this thread to solve this specific problem for MSVC, I do not
see a great need to use the git repository.

Compare working from the git repository with working with a tarball or a
zip file. (We should provide a zip file to make it easier for MSVC users).
They neither require git, help2man, makeinfo, gettext, nor bison.  Nor do
they require autoconf, autoheader, or automake which is the portion that
you are trying to obviate by using a MSVC project file.

So the autotools portion is only a small portion of handling a larger and
more complete problem which already isn't handled very well. Again, how
exactly on MSVC do you expect end-user installer to run the current test
suite if they aren't going to install additional tools?

And hand hacking the MSVC project files for the libcdio code, as it
currently exists, is already prone to future breakage. I don't know to what
extent you consulted the MSVC project files that were provided by XBOX, but
the commit message where these old MSVC project files were removed seemed
to give me the impression that they were largely useless. If we were to
split out CD-Text to a separate library, the MSVC project files would need
hand modification. Right? My point here isn't about how to make work for
MSVC developers, but rather that a more automatic solution is ultimately
needed, especially if you want to make it easy to work from git sources on
MSVC.

Another area of disagreement is how important and pervasive it will be to
build from git as opposed to from a tarball.

If binaries were distributed, that's what most would prefer, MSWindows or
not. Failing that, I think most would prefer a tarball or zip file. But
someone serious about developing from the bleading-edge git should be
prepared to install additional tools as necessary. Again, this is not
limited to a single platform or libcdio.

Finally we come to the issue of version.h. It is bad practice to add into
version control any derived or automatically-generated file. No one checks
into version control the autotools-derived files "configure' or
"Makefile.in". But these are universally distributed in autotools-derived
tarballs.

Worse is to check in something a derived file that is sometimes wrong. That
is why "Makefile" is never in version control, even though one can argue
that all Makefiles should be reliably overwritten when configure is run.

When you check in something that is derived a couple things happen. First,
there are extra commits just to keep the derived thing up to date. Second
and worse is that it is possible to inadvertently check in an erroneous
file.

I have had problems from users precisely when I had derived files checked
into version control that were incorrect for the user's environment. So
just take that as a fact and please don't ask about it again. It is
irrelevant whether autotools configuration is reliable enough to correct
the mistake that we make by checking verison.h into git.


On Wed, Mar 14, 2012 at 9:19 AM, Pete Batard <address@hidden> wrote:

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