[FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
jamrial at gmail.com
Sun Jan 24 22:40:53 CET 2016
On 1/24/2016 6:21 PM, Andreas Cadhalpun wrote:
> On 24.01.2016 21:40, Paul B Mahol wrote:
>> On 1/24/16, James Almer <jamrial at 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.
Yes, it is. You unknowingly broke something, and now pretend to keep it that
just so your change can remain committed.
> 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.
Are you seriously comparing adding a new feature that requires a newer version
of an external library, an intended change, with keeping a build usecase that
was unknowingly broken unfixed, and using no other argument than "It's fringe,
who does that anyway?".
>> 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.
No idea about symlinks on Windows, but if it works (and is tested before being
committed) then sure.
But if it doesn't and no other solution is found in the very short term, half
a dozen people have already told you that these changes must be reverted.
> Best regards,
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel