[FFmpeg-devel] [PATCH] remove MSVC-specific

Brian Brice bbrice
Sun Mar 9 08:04:33 CET 2008


On Sat, Mar 8, 2008 at 3:40 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
>
>  > On Sat, Mar 08, 2008 at 09:09:11PM +0000, M?ns Rullg?rd wrote:
>  >> Michael Niedermayer <michaelni at gmx.at> writes:
>  >>
>  >> > On Sat, Mar 08, 2008 at 09:31:03PM +0100, Diego Biurrun wrote:
>  >> >> On Sat, Mar 08, 2008 at 09:09:47PM +0100, Michael Niedermayer wrote:
>  >> >> > On Sat, Mar 08, 2008 at 09:03:00PM +0100, Diego Biurrun wrote:
>  >> >> > > On Mon, Feb 25, 2008 at 03:57:03PM +0100, Diego Biurrun wrote:
>  >> >> > > > Here is a patch to remove an MSVC-specific definition from
>  >> >> > > > libavutil/mem.h.  MSVC is not supported and now we have a
>  >> >> > > > proper fallback.  Besides, it seems that the identifier is
>  >> >> > > > wrong anyway and the condition is never true.  This proves
>  >> >> > > > that if there should be any sort of MSVC support, it
>  >> >> > > > should be maintained outside of FFmpeg where it might
>  >> >> > > > actually get some testing.
>  >> >> > >
>  >> >> > > No one seemed to be against this patch, so here is an
>  >> >> > > updated version.
>  >> >> >
>  >> >> > patch rejected :)
>  >> >>
>  >> >> :)
>  >> >>
>  >> >> Seriously, we do not provide MSVC infrastructure in other places, why in
>  >> >> this one?
>  >> >
>  >> > Why not? :))
>  >> >
>  >> > Seriously, its one hunk less to maintain for people who have hacked their
>  >> > ffmpeg to be msvc compileable. And it does no harm to us.
>  >>
>  >> It adds to the maintenance burden for everybody, and it is a piece of
>  >
>  > What kind of maintaince can these 2 lines need?
>
>  What good do those lines do to the rest of FFmpeg as present in svn?
>  If the answer is "nothing", they should go.
>
>  Two lines never seems like much, but two lines here and two lines
>  there soon add up to a lot.
>
>
>  > Its like saying the a fourcc in the table of fourccs for a codec we dont
>  > support adds a maintenance burden for everybody ...
>
>  No, it's not.  A table entry will never be rendered incorrect by
>  code changes.
>
>
>  >> code that will never receive any testing whatsoever.  Both of these
>  >> are bad.
>  >>
>  >> > Maybe we can one day even support MSVC fully, it just needs MSVC to
>  >> > support standard C or someone to come up with a clean workaround. Like
>  >> > a little perl script to convert the problematic syntax before feeding it
>  >> > to the compiler.
>  >>
>  >> You've obviously never had the misfortune of being required to use
>  >> msvc for anything.  Or my sarcasm detector is in dire need of
>  >> maintenance.
>  >
>  > No, i was lucky and just had some volunteerly contact with MSVC
>  > which ended after a week or 2 of twice daily hard resets. That was
>  > maybe 10 years or so ago IIRC
>
>  The situation hasn't improved.

These flames are becoming pretty ridiculous and very childish.  As
someone that has successfully compiled ffmpeg with MSVC, and also uses
mingw compiled libraries with MSVC projects, the stuff you are always
trying to remove only become very bothersome for someone like me.  And
I know I'm not alone!  I appreciate things like this available in the
code already.  I certainly don't appreciate the removal of these
things because of your own personal grudges and ignorances.

I don't know you or know any of your experience, but I can guarantee
you that MSVC has improved for the better in 10 years time.  In my own
opinion, I didn't like MSVC 6 very much (10 years ago), but thoroughly
enjoy the current product.  It's certainly a much better improvement
from using the alternative, MinGW, in a Win32 environment.

I really do like the ffmpeg project a lot and I appreciate the work
that you guys and everyone else contributes.  It's great that you guys
prefer gcc as your compiler, but the flaming about other compilers
(and other languages!) is getting to the point where it's
unprofessional.


-- 
Brian Brice
http://www.heapify.org/




More information about the ffmpeg-devel mailing list