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

[Rocky Bernstein]

On Thu, Mar 15, 2012 at 11:40 AM, Pete Batard <address@hidden> wrote:

> ...
> Then you are probably going to alienate MSVC users.


Is the glass half empty or half full? Right now we don't *have* any MSVC
users, except yourself. The steps you have taken so far then have made
things easier for MSVC users for the next release. So I'd turn statement
around to ask to what extent do we want to *attract* MSVC users. 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. But in a separate post, I'll solicit opinions. And perhaps
not supporting MSVC is not a bad thing.

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.


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

... I don't expect MSVC users to run any libcdio tests. Ever.
>

This doesn't compel me to want to include MSVC support.

You may be cool to the idea that users provide bug testing for you free.
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. People sending patches I would prefer, or
perhaps *require*, to run the tests before I do. Furthermore, when someone
sends a bug fix, I generally want a test added to demonstrate that the bug
is fixed.

...
> Unless you can think of something else to easily duplicate testing for
> MSVC, testing of libcdio for MSVC is not going to happen. The closest we
> will have is MinGW testing, with the hope that the binaries will not
> deviate to much.


Not encouraging.


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


> ...
> And again, same discussions we've had on libusb, with the outcome that
> making everybody ditch autotools because of MSVC was not acceptable.


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




> ... Avoidable complexity


One could make the same argument regarding including MSVC.  Or again, is
adding all of the complexity to support worth it? Are you volunteering to
be the contact person for MSVC-related problems?


...
> OK. I'm still not convinced,


I wasn't expecting you would be convinced.


but sure, you want to consider the matter closed, let's consider it closed.


Thanks.


> But since I still want to help MSVC git building libcdio, without
> incurring extra requirements, I'll add a pre-build step to generate the
> version.h in MSVC and we'll take it from here.
>

Thanks again.

>
> Regards,
>
> /Pete
>
> [1] https://github.com/pbatard/**rufus <https://github.com/pbatard/rufus>
>
>