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

[Rocky Bernstein]

I could try to go through the corrections
- it is doubtful that vlc would ever switch to MSVC and support for it has
always been minimal to the point of almost nonexistent.
- ruby-debug-base is used more as a library rather than an end-user thing,
and
- libcdio does have standalone programs that are used far more often than I
had even imagined they would

But going into the details doesn't change central matters. And it just goes
off on more tangents.
So for sake of argument, let's assume vlc is on the verge of unrolling MSVC
binaries and that ruby-debug-base is an end-user debugger and libcdio is a
pure library.

More central to the main point was this weird distortion:

   Treating MSVC as a minor platform that can be brushed aside ...

I wondered for a while where that mis-impression comes from.  I suppose is
it partly from the remark I made that perhaps not supporting MSVC is not a
bad thing. I didn't mean this a reflection of the market penetration of
MSVC or how wonderful it would be for libcdio.

Rather I was thinking along a very narrow set of concerns of whether how to
manage the project when there are two very different philosophies of the
project.  I can't accept the means by which you work by any more than you
are willing to accept mine.

For example, the importance of having automated tests that users can easily
run. Or the burden of having programmer install additional tools -- and
what they are -- when working from the development repository.

I think it clear that we're not going to bridge this gap easily in the near
future. That's why I suggested the branch which I was hoping would be seen
as more official and with closer integration than say forked project which
what I've had to do in similar circumstances. It is what we've done with
paranoia code. (At one point Monty offered to give libcdio project space on
the Xiph.org repository, but since we had already had this in a repository
and since paranoia wasn't the entire thrust of the project it didn't make
sense to me. I'm trying to look for a solution that would be more
accommodating.)

So in sum a lot of the discussion has been to try to come up with one set
of rules for two different philosophies or trying to convince one person to
follow some other project or software methodology. For the short term, I
can't see how to do it short of something like treating these as two
possibly strongly aligned or related projects.



On Wed, Mar 21, 2012 at 10:24 PM, Pete Batard <address@hidden> wrote:

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