On Sun, Jan 24, 2016 at 10:48 PM, Andreas Cadhalpun <andreas.cadhal...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel