[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, hea
From: |
Pete Batard |
Subject: |
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming |
Date: |
Mon, 19 Mar 2012 23:07:17 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
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
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, (continued)
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/09
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/10
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/11
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/12
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/14
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/15
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/18
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming,
Pete Batard <=
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/20
- Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Pete Batard, 2012/03/20
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming, Rocky Bernstein, 2012/03/05
- Prev by Date:
Re: [Libcdio-devel] CD-Text API changes
- Next by Date:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Previous by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Next by thread:
Re: [Libcdio-devel] Pete Batard's Changes (MinGW, MSVC, UDF, Joliet, header ...) merged in. Leon's CD-Text changes coming
- Index(es):