[FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
h.leppkes at gmail.com
Mon Jan 25 12:02:16 CET 2016
On Mon, Jan 25, 2016 at 11:09 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun
>> <andreas.cadhalpun at googlemail.com> wrote:
>>> On 24.01.2016 22:57, Hendrik Leppkes wrote:
>>>> 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".
>>> Oh well, MSVC just doesn't want this to work...
>>> Then let's do it the other way around: create a link from the destination
>>> path to the source path.
>>> If that link can be created, it can be used as relative path and otherwise
>>> one can still use the full source path.
>>> Attached is a patch implementing this.
>>> It should not be possible that this breaks anywhere.
>>> Feel free to apply this if it makes MSVC builds work again.
>> msys doesn't seem to like creating directory symlinks with ln -s, for
>> some reason it copies the folder instead, which is of course terribly
>> Could try to use the windows link creating function, but thats
>> probably too much trouble.
>> If we already have a way to fallback to the "old way", maybe this
>> could be put under a OS conditional, ie. exclude msys/cygwin?
> Looking at it, we even have a handy configure property that identifies
> problem systems:
> if enabled dos_paths; then....
Thinking about it dos_paths refers to the target OS, not the host, but
a similar condition can of course be found to put this to bed.
More information about the ffmpeg-devel