[FFmpeg-devel] [PATCH] remove MSVC-specific
Tue Mar 11 16:31:00 CET 2008
On Tue, Mar 11, 2008 at 03:18:01PM +0100, Michel Bardiaux wrote:
> Reimar D?ffinger wrote:
> > I do not know who you think of, but if you haven't noticed gcc,
> > binutils, Solaris userland, OS/2 all have received similar levels of
> > flames (and in the case of OS/2 IIRC much harder to reimplement code was
> > removed than this MSVC stuff).
> I remember vividly when building with Mingw got you the message ?se a
> real OS"every time you used ffmpeg...
How shocking. But anyway, it was added as a somewhat bad joke on 31. March,
on April 1st someone complained, though obviously everyone had more important
things to do than even reply, discussion started on April 4th and
concluded on the same day with the decision to remove it.
On April 15th Diego finally implemented the decision. Doesn't seem to me
like it truly bothered anyone.
> > And lastly: if there are more than a handful MSVC users, you also have
> > the option of doing a fork and keeping it up to date, thereby proving
> > that there are people willing to maintain that stuff and it is mot much
> > effort to maintain.
> You know perfectly well its not really an option, because under the
> rules of the ffmpeg lists, the fork would have to do *all* the support
> for its users. Not just support of the parts not in the mainstream svn.
Where is the problem? The "users" would be everyone building with MSVC,
they rather should be able to most of the support themselves, and anyway
they don't get the slightest bit more support currently.
Not to mention that the fork could have a policy of "reproduce ffmpeg
bugs with upstream, and send bugs there, we only accept bugs against out
This will not change much different if you get MSVC support included here,
MSVC users will care and fix anything that smells even remotely like
MSVC might have caused it, but the same happens to OS/2 etc. users.
Not to mention that bugs usually are supposed to be reproduced with
ffmpeg/ffplay in most cases anyway, and compiling those with MinGW for
comparison is not that hard.
More information about the ffmpeg-devel