On Thu, Mar 15, 2012 at 11:40 AM, Pete Batard <[email protected]> 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> > >
