On 10/18/2017 1:42 AM, Diego Biurrun wrote: > On Tue, Oct 17, 2017 at 11:36:03PM -0300, James Almer wrote: >> On 10/17/2017 10:22 PM, Diego Biurrun wrote: >>> A private fallback roundf() implementation is not worth the trouble >>> for a fringe feature like libxvid encoding. >> >> Removing libxvid support from every MSVC <= 2012 build (and maybe also >> other compilers) to save six lines in an internal header seems a bit >> unjustified... > > Thanks for reminding me which version of MSVC is the sensible one. :) > MS is now distributing them free of charge, so is there any good reason > not to just use a sensible version?
No, there's IMO no reason to use a MSVC release older than 2013, but then again, some people/distros still rock GCC 4.4... > > The roundf fallback was added in 2007, probably for some BSD flavor or > some similar fringe thing. The BSDs eventually improved and started > fixing their libcs' POSIX capabilities instead of (literally) patching > all applications. I doubt any platform we still care about lacks roundf. > > Mind you, I care little about this patch and will just drop it. At some > point I think we should just get rid of all this fallback cruft and > just require a POSIX-compatible system. > >> And i don't know if you're aware that the scene of xvid rips is >> (inexplicably) still alive. > > But what do they use for encoding? I expect it would be the libxvid > encoder itself. I have no idea. I just know that xvid is still a thing, so removing support for its main encoder just to clean six lines of code, even if only for crappy compilers, seemed somewhat unjustified. > >>> --- a/configure >>> +++ b/configure >>> @@ -2388,7 +2388,7 @@ libx262_encoder_deps="libx262" >>> libx264_encoder_deps="libx264" >>> libx265_encoder_deps="libx265" >>> libxavs_encoder_deps="libxavs" >>> -libxvid_encoder_deps="libxvid mkstemp" >>> +libxvid_encoder_deps="libxvid mkstemp roundf" >> >> Wouldn't this keep libxvid enabled (thus libavcodec linking to it)? > > Not since I overhauled the link dependency handling :-))) Nice! > > Diego > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel > _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
