Re: [Libcdio-devel] RFC: Support for non-POSIX systems?

[Pete Batard]

On 2012.03.21 10:02, Rocky Bernstein wrote:
> > I am a convinced Linux user but imho as long as the projects using libcdio
> > like VLC are released for other systems we should try to do so, too. The
> > demand is there.
>
> There are a couple of possible misunderstandings here.

Indeed there are. Please also allow me to go through them.

> The first vagueness which is used for distortion is the implied view that
> since VLC supports MSVC so we should too. The preferred build method for

Note the use of "preferred", which isn't an exclusive qualifier.

> VLC on Microsoft Windows is via mingw cross compilation.  One can build a
> minimal VLC (that is without all of the features usually used) with MSVC,
> but it is far from easy to do.

Still, one can, and I'm pretty sure that, if MSVC is supported, albeit 
in a limited fashion, one will be able to submit bugfixes or add 
features that are MSVC related and see them integrated to the VLC 
project, to benefit other MSVC users.
As awesome I think MinGW is, who knows if in the future MSVC may not 
become the preferred build method for VLC on Windows?

> Most people who run VLC on Microsoft Windows
> got it from downloaded binaries and that is the VLC's stated preferred
> method.

I will assume that you are talking about the VLC library, and not the 
VLC end-user application, as comparing the means of obtaining an 
end-user app, which of course very few people would recompile from 
source, to the means of obtaining a library to use while developing an 
app, where the target demographics is not the same, are very different 
matters. Developers != end-users.

> And chances are that if you are running VLC on Microsoft Windows,
> you did not build it from source.

If you are "running VLC" on Windows then you are running the VLC 
application client, and aren't developing anything. Can you "run 
libcdio" as a standalone app on any platform?
If not, please be mindful about comparing what can actually be compared 
to try to prove a point.

So, assuming that what you mean is "if you are developing a VLC based 
application on Windows, chances are that you are not rebuilding the VLC 
DLL from sources", I would agree that it probably holds true. Yet, I'm 
also pretty sure that some MSVC developers will also not want to use a 
ready-made VLC.dll, either because it's too cumbersome or they want to 
just use a subset of features or whatever other reason, and therefore 
will want to recompile it from source, most preferably in the 
development environment that suits them most.

So the question, once again, becomes: How many MSVC users of libcdio do 
we expect to want to recompile from source. And from what threshold 
would we consider that number important enough?

> For a popular debugger on Ruby I was providing windows binaries. And again
> that's what most people used.

Seems you're comparing end-user apps and libraries again. That is unless 
your debugger came as a library. Please don't, as it makes your point 
rather irrelevant. End users of an application are a very different 
breed from developers, with one category being likely to want to 
recompile something, if it suits them.

> I too used the same cross-compilation via mingw.

Yes, using MinGW all the way is fine when you're recompiling a 
standalone app that you don't plan to integrate in another project, and 
therefore where very important additional considerations, that need to 
be taken into account for a library, do not matter.

But what if you have been tasked by your boss to develop an app in MSVC 
(because that is dev-env that you company uses, as it happens to be the 
most widespread on Windows) that also accesses optical media? Pretty 
sure that, when your boss sees you going through an install of MinGW 
(which you may or may not be familiar with), just so you can recompile 
the library to tailor it to your needs, he's going to ask: "Why isn't it 
possible to forego MinGW requirement and do the same task in MSVC in the 
first place? Or can't we use a library that doesn't require MSVC 
proficient employees needing to familiarize themselves with MinGW, just 
so we can tailor it to our needs? Using a non MSVC friendly libcdio is 
adding to our development cost."

> So again, "used on MS Windows" and even "popularly used on MS
> Windows" does not mean it was compiled with MSVC or was built on a system
> that didn't have POSIX tools.

Not sure what the point is. "does not mean it was" != "means it never was".

If most people don't do something, it doesn't mean nobody does it/will 
ever do it. And if the population you are looking at is large enough, as 
would be the case for MSVC developers, then even if only a small 
fraction deviates from what others would tend to do, that number may not 
be that insignificant.

> > What we do need are people to test and maintain the releases for the
> > different systems. We can talk a lot about what to do or not to do but
> > without individual care it will not work out. Every release has to be
> > tested on every system we claim to support
>
> I no longer claim to support any system for the next release precisely
> because the people who have drivers contributed code and disappear.

Of course you can't, and I don't believe anybody expects you to do so. 
Therefore, unless you consider that the supported system is obsolete and 
want to remove it, you should just state that driver support for systems 
that nobody has tested or expressed interest in in a long time is 
provided "AS IS", i.e. may or may not work as advertised. Then you can 
just continue focusing on the systems you can test or that you see as 
relevant. This way, if someone does manifest some interest, they still 
have something that they can get started with. And if you want to 
continue treating MSVC as an "AS IS" platform, I'm 100% fine with that too.

> That's
> the case for OS/2, BSDI (or rather perhaps these are dead OS's or no longer
> of concern). But it's also true for OS/X. Not sure where FreeBSD and NetBSD
> stand in all the variations of OS releases. And ditto for the distros of
> GNU/Linux.  Most packagers of libcdio tend to look at libcdio after the
> release not before. Look at how Debian and RedHat releases lag behind.

I'm not sure how bringing up systems that are more or less obsolete is 
relevant for the MSVC discussion, since MSVC and Windows are very much 
alive and will, hopefully, generate developer interest for libcdio.

> > This does not have to be the case with git. If a POSIX developer submits a
> > patch imho it would be wrong asking him to test it with MSVC.
>
>
> This is the other area which is used for distortion and the confusion is
> frustrating because I would have thought you should known better.

I think Leon is simply referring to a point I made in a previous mail, 
where indeed I exaggerated the logical consequences of what you seemed 
to be requesting MSVC developers to be doing, should you include MSVC 
support in libcdio, by reverting the situation.

> Have I
> ever asked you to test on Microsoft Windows? Or Solaris? Or *BSD*?

No, but, unless I misread you, you were implying that, if MSVC is to be 
supported, then MSVC developers who submit patches should only have 
their patches accepted if they also test on POSIX, which is the same 
situation with only the name of the variables changed. This is where we 
were trying to make you realize that such a request may be construed as 
unfair, especially as you are again confirming that you would never ask 
for the opposite.

> Discussing practices which you should know don't exist ("straw arguments")
> is pointless and harmful because it is used for further exaggeration.

So the practice of asking a non-POSIX developer to test on MSVC, should 
such a test be made easily available, is a straw argument, but the 
practice of asking an MSVC developer to test on POSIX is okay?

> But here I want to also point out that about half of the tests are written
> in C. So although the build system uses POSIX shell, many of the tests
> don't need POSIX shell although that's currently what is used to invoke the
> tests.

Are you saying that MSVC developers should just take the time to 
*manually* check a series of tests, that are automated on every other 
platform? In that case, we might as well do it the way I advertise, 
which is no official testing required (since we don't have anything 
formalized), and just rely on the developer performing ad-hoc checks at 
their convenience.

Again, unless I am misconstruing what you are implying, and I hope I do, 
you appear to be okay with placing a burden on MSVC libcdio developers 
that you would not place on POSIX ones.

> One set of tests is just compiling some of the example C and
> possibly C++ programs, and then running some of those to see that they run
> and give a zero exit code.

Last I checked there were tens of individual tests that one can run for 
libcdio.

Unless these tests are automated, I don't see it as reasonable to expect 
people to manually run them one by one, even if it's only "some", even 
more so as "some" is subject to interpretation.

Now, if "some" equates running a quick ad-hoc check of the 2 sample 
executables that the -pbatard branch currently provides for MSVC 
(extract and cd-info), then I don't have much of an issue with trying to 
*encourage* people to do so when possible, with the caveat that, even 
with 2 executables, if each needs to be ran multiple times for ISO9660, 
UDF, CD-Text, etc, it may become quite taxing...

Regards,

/Pete