[FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds

[Hendrik Leppkes]

On Sun, Jan 24, 2016 at 10:48 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 24.01.2016 22:38, Michael Niedermayer wrote:
>> On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
>>> The patch to use relative for DST_PATH should make FATE green again, as
>>> no MSVC FATE client I saw builds across drives.
>>
>> Please either fix fate and the cases that the developers need or
>> revert. some fate clients are red since 2 days, thats not good
>
> I would push that patch if someone confirmed that it fixes the usual
> MSVC use case, in particular how the FATE clients work.

We've had our fill of half-baked solutions for this issue. As others
have stated, it needs to restore full previous functionality, or be
reverted and go through a proper rigorous review were the merits of
breaking existing functionality can be discussed and decided.

>
>> also everyone please calm down, we do have a common goal
>
> Indeed.
>
>> if anyone has an idea on how to solve these problems or can provide
>> some form of assistance to andreas (i belive he doesnt have a msvc
>> system), please help him
>
> Yes, testing that patch would be really appreciated.

I tested all proposed solutions and patches, I told you what didn't
work. If we can't find a fix soon, it needs to be reverted to restore
the status quo.

>
> If people really think that cross-drive-out-of-tree-building-on-MSVC
> needs to be supported, I'd be willing to try the link approach, or,
> if that also fails, just creating the objects in the source directory
> and copying them afterwards.

While links are in theory a good idea, creating directory links on
windows requires elevated privileges. Don't ask me why, I don't know,
but that makes this unfortunately impractical.
Copying files around between different physical media is not a
solution, but an ugly hack and a build performance regression. See
earlier point about re-opening the review phase of this change to
discuss such "solutions".

>
> But before spending time on that I'd like to be sure it really fails,
> as Henrik seemed to say that it should work, when using unix path.
>
> Has someone tested that?

We're not using unix path, thats the entire point of this excercise,
we need a valid windows path to pass to the MSVC compiler, because the
unix->windows conversion from msys doesn't catch on.
If we could use unix path, absolute path would just work.

- Hendrik