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.18 04:07, Rocky Bernstein wrote:
> Is the glass half empty or half full? Right now we don't *have* any MSVC
> users, except yourself.

Indeed. And by the looks of it, it doesn't look like you're willing to 
take any steps to encourage more MSVC users to use libcdio, by applying 
a *pragmatical* approach to MSVC support.

Especially, you may want to acknowledge that there are quite a few more 
developers using MSVC than any other development environment out there, 
and therefore that the interest in an MSVC friendly libcdio is likely to 
be quite a bit more important than, say, the interest in an Amiga 
friendly libcdio (for which, by the way, partial support is at least 
partially already available, since there exist Amiga specific statements 
in types.h).

There is such thing as market penetration considerations.

> So I'd turn statement
> around to ask to what extent do we want to *attract* MSVC users.

Please don't use "we" here.

You are the only one pondering as to whether you want to attract MSVC 
users so far, whereas my latest proposal contained all the steps I saw 
necessary to *actually* attract them.

It did so by making libcdio as straightforward and easy as possible to 
use, through the removal of encumbrances that MSVC developers wouldn't 
want to concern themselves with, such as a brand-new, time-consuming and 
prone-to-breakage MSVC testing implementation (only really useful for 
the maintainers of the library, rather than people who merely reuse it), 
or having to jump through hoops just to get a 2 line version.h file created.

> Given what
> you report, excerpted below (all of these are just very long) I am getting
> the impression that we probably can't go as far as you want towards MSVC
> friendliness.

We very much can (see above), but not if you are focused on making what 
are essentially secondary matters for library users more important than 
they should really be.

> And perhaps not supporting MSVC is not a bad thing.

Perhaps not a bad thing for *you*.

However, I don't think you can state that it wouldn't be a bad thing for 
the collective of MSVC developers out there who may have some use for a 
libcdio like library and could avoid wasting their time reinventing the 
wheel.

Are you not developing a cross-platform libcdio in the hope that it will 
be useful for others?

> Code I have seen that supports MSVC and non-POSIX systems -- like GNU Make
> -- does so at a great price. Often there are people dedicated to making
> things work on just MSVC.

Same thing is true for projects that originated from MS environments and 
then went cross platform, so I'm not sure what your point is.

Or are you saying you're afraid you won't have enough contributors to 
help you with MSVC support, and therefore that it is pointless to do 
anything to make libcdio MSVC friendly and attract such contributors in 
the first place? Looks like a self fulfilling prophecy to me...

> ... Bug is fixed in git repo or new feature is added, and next tarball;
> > release is whenever =>  developer wants to use git.
> >
> > Also, if developer finds bug, they may want to feed it back =>  better be
> > in a position to do so right from the start. If I'm starting to pick up
> > issues with software that I reuse, even if I originally picked a tarbal,
> > then I'm probably going to switch to using the git version so that I can:
> > 1. ensure that I'm not missing something that is only fixed in git
> > 2. feed back patches if I address problems.
>
> People who work this way should have more than MSVC development tools. I'd
> expect at least MinGW development tools as needed.

Nope. They have git and the MSVC debugger. That's all they need. As a 
matter of fact, the first thing I did when I encountered issues with the 
now obsolete paranoia in MinGW tests was create a project for MSVC, so 
that I could fix things more easily. And as a side note, had the 
paranoia tests not been there to fix in the first place, I could have 
spared about one week of development on a task that was pretty much 
useless since bound for removal. Thus I could actually have done with 
less or even no testing at all in libcdio.

But if you want a real life example, in all the development I do, I 
spend about 95% of my time with Visual Studio, and would spend 100% if I 
didn't *choose* to provide MinGW support in order to be friendly for 
people who may not have access to that environment => my MinGW usage is 
pretty much limited to testing for breakage, as well as potentially 
releases when they present some advantage over VS (eg. smaller or easier 
to script for). I'm pretty sure that if you ask around, you will find 
that most developers tend to avoid having to install more than one 
development environment, especially when their goal is usually to 
develop an application for one target only.

> ... I don't expect MSVC users to run any libcdio tests. Ever.
>
> This doesn't compel me to want to include MSVC support.

And thus MSVC people will be deprived of a library that would probably 
work just fine for their needs because *you* are unhappy that it won't 
come with tests and expect it to blow up as soon as used there.

I'm afraid that this focus on internal testing, as the only way to 
declare the library fit for consumption, makes even less sense as the 
simplest means of testing I could think of, which is picking as many 
ISOs as one can and churn them through libcdio, did a magnificent job at 
identifying major bugs, that internal tests would probably never have 
been implemented for (Joliet + El Torito, >4GB file in a >4GB ISO, 
etc.). As a matter of fact, had libcdio not come with tests, it probably 
wouldn't have changed much with regards to the patches I submitted.

If libcdio was proprietary, closed source, and expected to receive 
little to no user feedback, I'd agree with you that having a 
comprehensive set of tests for all supported platforms would be crucial. 
But it is none of that, therefore Cathedral building rules need not apply.

> You may be cool to the idea that users provide bug testing for you free.

Yes. And others seem to be too. That's called the Bazaar approach. Quite 
a few FOSS projects seem to happily use it, often to great success.

> But aside from the fact that as a user I dislike that, as someone who is
> called on to fix the bugs, I definitely don't want to be the guinea pig for
> a patch that are fed back to the code. The minimum standard for a patch is
> that it not break existing tests.

In that case, we might as well be consistent and ask Linux developers 
who submit a patches to make sure that they don't break MSVC tests, if 
we start making such tests available. I could probably provide a guide 
on how to install the freely available WDK in the freely available Wine 
to run those, so there wouldn't be much of a reason not to test MSVC. 
And as you indicated, requiring libcdio developers to install extra 
development components and jump through hoops is fair game, as long as 
it improves testing...

Or should it be acceptable for POSIX users not to test non-POSIX when 
they can, but not the opposite?

> People sending patches I would prefer, or
> perhaps *require*, to run the tests before I do.

There's a difference between encouraging and requiring.

Despite what I seem to imply above, I agree that, time permitting it is 
preferable to check on more than one platform. Time permitting, this is 
also what I try to do (I tend to check MSVC+ MinGW + Linux before 
proposing a set of patches. Also check cygwin from time to time. And 
this is VERY time consumming, especially as autotools are an order of 
magnitude slower on anything Windows). I would expect MSVC-libcdio 
contributors to naturally try to test either one of MinGW or Linux too.

And I have to stress out time as THE major factor in all of this 
discussion. It's arguably the most valuable resource everybody has, 
therefore the one that we must take steps to ensure it is wasted as 
little as possible collectively.

If you are not going to provide straightforward MSVC support, when it 
has been demonstrated that it could indeed easily be provided, then you 
are ensuring that MSVC developers will have to waste their most valuable 
resource.

> Furthermore, when someone
> sends a bug fix, I generally want a test added to demonstrate that the bug
> is fixed.

If it's a preference, that's fine. But if it's a requirement, I don't 
think you will see as many contributions as you'd like...

> > ... As long as we have project files that can build the executables or
> > libraries they were designed for, so that these executables can be used and
> > tested with applications, that's fine with me.
>
> Yes, but it's not fine with me. It is not uncommon when someone reports a
> bug for me to ask if the tests worked.

That's only relevant if they provided a test, which I'd expect few to 
do, because it's time consuming and the person who patched the bug would 
probably have the means to test a real-life scenario and see standalone 
limited duplication as a waste of time they have in short supply.

> I suspect that's going to be the case here too. Are you volunteering to
> rewrite code using CMake?

Of course not, especially since I have seen that the pragmatic approach 
of maintaining 2 sets of project files seems to work quite well in 
practice (libusb). Unless CMake becomes the de-facto standard, forcing 
everybody to become familiar with CMake will be yet another collective 
time waster => something we should try to avoid.

> > ... Avoidable complexity
>
> One could make the same argument regarding including MSVC.

Except the audience very much matters. Avoidable complexity for whom? 
You only, or the collective of developers for one platform? My MSVC 
support proposal does not expect anything from POSIX users, especially 
as I wouldn't expect anybody else but me to ever check for breakage there.

he approach you had for the existing MSVC/XBOX support was fine: leave 
it as is, and if found broken, wait for interested people to fix it. Why 
suddenly change it?

> Or again, is
> adding all of the complexity to support worth it? Are you volunteering to
> be the contact person for MSVC-related problems?

I already indicated I would, again, time permitting.

I think it is pretty much implied that, when someone provides a set of 
patch to add a new platform support, they become the de-facto 
sub-maintainer for that platform, for as long as they can afford such a 
position.

Regards,

/Pete