On 24.01.2016 21:40, Paul B Mahol wrote: > On 1/24/16, James Almer <jamr...@gmail.com> wrote: >> It is absolutely unacceptable to say "do something else" as a "workaround" >> to a breakage introduced by a new feature. >> >> Unless you can fix this for every usecase that was working before this >> in the very short term, as several people told you already these patches >> *must* be reverted until a proper fix is found.
That's not very reasonable. Other changes also broke things that worked before. For example before commit 94c20de one could build ffmpeg with x265 version X265_BUILD 17, and afterwards it requires at least X265_BUILD 57. That's also a regression, but the workaround is to use a newer x265 version. > Yes, it *must* be reverted, FATE shouldn't be red. The patch to use relative for DST_PATH should make FATE green again, as no MSVC FATE client I saw builds across drives. If it's really necessary to continue supporting this fringe use case, one could make configure create a link to the destination folder. Unless links also don't work across drives. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
