On Mon, Jan 25, 2016 at 11:09 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: >> On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun >> <andreas.cadhal...@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 >> slow. >> 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. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
