On 25.01.2016 20:28, Hendrik Leppkes wrote:
> On Mon, Jan 25, 2016 at 8:07 PM, Andreas Cadhalpun
> wrote:
>> On 25.01.2016 11:01, Hendrik Leppkes wrote:
>>> msys doesn't seem to like creating directory symlinks with ln -s, for
>>> some reason it copies the folder instead, which is of course terrib
On Mon, Jan 25, 2016 at 8:07 PM, Andreas Cadhalpun
wrote:
> On 25.01.2016 11:01, Hendrik Leppkes wrote:
>> 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.
>
> There is a fast configure check, wh
On 25.01.2016 11:01, Hendrik Leppkes wrote:
> 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.
There is a fast configure check, which I added to prevent actually
creating the link to the source dir
On Mon, Jan 25, 2016 at 11:09 AM, Hendrik Leppkes wrote:
> On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes wrote:
>> On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun
>> wrote:
>>> On 24.01.2016 22:57, Hendrik Leppkes wrote:
While links are in theory a good idea, creating directory links
On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes wrote:
> On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun
> 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,
On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun
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.
>
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
On Sun, Jan 24, 2016 at 01:46:50PM -0800, Timothy Gu wrote:
> On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
> >
> > That's not very reasonable.
> > Other changes also broke things that worked before.
> > For example before commit 94c20de one could build ffmpeg with x265 versio
On Sun, Jan 24, 2016 at 10:48 PM, Andreas Cadhalpun
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
On Sun, Jan 24, 2016 at 06:40:53PM -0300, James Almer wrote:
> > 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
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 devel
On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
>
> That's not very reasonable.
> 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.
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 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 usecas
On Sun, Jan 24, 2016 at 10:21:14PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 21:40, Paul B Mahol wrote:
> > On 1/24/16, James Almer wrote:
> >> It is absolutely unacceptable to say "do something else" as a "workaround"
> >> to a breakage introduced by a new feature.
> >>
> >> Unless you can
On 24.01.2016 21:40, Paul B Mahol wrote:
> On 1/24/16, James Almer 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 te
On 1/24/16, James Almer wrote:
> On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
>> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>>> andreas.cadhal...@googlemail.com> wrote:
>>>
On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, J
On 1/24/2016 5:20 PM, Andreas Cadhalpun wrote:
> On 24.01.2016 21:14, Ronald S. Bultje wrote:
>> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
>> andreas.cadhal...@googlemail.com> wrote:
>>
>>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpu
On 24.01.2016 21:14, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> On 24.01.2016 20:54, Hendrik Leppkes wrote:
>>> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
>>> wrote:
On 24.01.2016 20:40, Hendrik Leppk
Hi,
On Sun, Jan 24, 2016 at 09:10:53PM +0100, Andreas Cadhalpun wrote:
> When the build environment has so many limitations some things just
> don't work.
>
> Why is it necessary to do MSVC out-of-tree builds across different
> drives?
It's not, but it used to work, and it doesn't work now. Thus
On Sun, Jan 24, 2016 at 8:54 PM, Hendrik Leppkes wrote:
> Its just how it works. Relative paths can't switch drive in windows
> path, no matter how many ..'s you chain.
> Once you hit the root of a drive, .. just redirects to itself, just
> like a unix / would, except that you get one per drive in
Hi,
On Sun, Jan 24, 2016 at 3:10 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 24.01.2016 20:54, Hendrik Leppkes wrote:
> > On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
> > wrote:
> >> On 24.01.2016 20:40, Hendrik Leppkes wrote:
> >>> Unfortunately that doesn't work
On 24.01.2016 20:54, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
> wrote:
>> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>>> Unfortunately that doesn't work when there is no common path, ie.
>>> sources on another drive (say D:) as my build directory (say C:)
>>
>>
On Sun, Jan 24, 2016 at 8:51 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 20:40, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
>> wrote:
>>> On 24.01.2016 17:14, Henrik Gramner wrote:
>>> I have a hard time believing that there are environments, where one
>>> can't
On 24.01.2016 20:40, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
> wrote:
>> On 24.01.2016 17:14, Henrik Gramner wrote:
>> I have a hard time believing that there are environments, where one
>> can't use absolute paths...
>
> Its about the combination of msys and i
On Sun, Jan 24, 2016 at 7:27 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 17:14, Henrik Gramner wrote:
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
>>> Windows doesn't particularly care which slash direction you give it,
>>> so no, that changes nothing. I'm not quite sure why it fai
On 24.01.2016 19:37, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
>> I can't reproduce this. The path is only included in the debugging
>> information.
>> And that happened even more before my change.
>
> I just built in-tree with:
>
> ./configure && nic
Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> I can't reproduce this. The path is only included in the debugging
> information.
> And that happened even more before my change.
I just built in-tree with:
./configure && nice make -j 8, and then I get:
/tmp/ff2 $ grep /tmp/ff2 f
On 24.01.2016 18:58, Nicolas George wrote:
> Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
>> I think Andreas' original patch removed that so in-tree and out-tree builds
>> are bit-exact (i.e. the pathnames to in-tree source files are identical
>> between the two build types).
>>
>>
On 24.01.2016 17:14, Henrik Gramner wrote:
> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
>> Windows doesn't particularly care which slash direction you give it,
>> so no, that changes nothing. I'm not quite sure why it fails with the
>> include path this way, maybe some msys shenanigan
Le quintidi 5 pluviôse, an CCXXIV, Ronald S. Bultje a écrit :
> I think Andreas' original patch removed that so in-tree and out-tree builds
> are bit-exact (i.e. the pathnames to in-tree source files are identical
> between the two build types).
>
> I don't know if that's worth it. Andreas seems t
On Sun, Jan 24, 2016 at 10:14 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner wrote:
>
>> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes
>> wrote:
>> > Windows doesn't particularly care which slash direction you give it,
>> > so no, that changes nothing.
Hi,
On Sun, Jan 24, 2016 at 11:14 AM, Henrik Gramner wrote:
> On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes
> wrote:
> > Windows doesn't particularly care which slash direction you give it,
> > so no, that changes nothing. I'm not quite sure why it fails with the
> > include path this way, m
On Sun, Jan 24, 2016 at 5:02 PM, Hendrik Leppkes wrote:
> Windows doesn't particularly care which slash direction you give it,
> so no, that changes nothing. I'm not quite sure why it fails with the
> include path this way, maybe some msys shenanigans.
> For fun and giggles, I hard-coded the corre
On Sun, Jan 24, 2016 at 4:56 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 16:29, Hendrik Leppkes wrote:
>> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
>> wrote:
>>>
>>> So here the correct path is passed to '-Fo'.
>>>
D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
On 24.01.2016 16:29, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
> wrote:
>>
>> So here the correct path is passed to '-Fo'.
>>
>>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>>> C1083: Cannot open compiler generated file:
>>> 'D:\Multimedia
On Sun, Jan 24, 2016 at 3:45 PM, Andreas Cadhalpun
wrote:
>
> So here the correct path is passed to '-Fo'.
>
>> D:\Multimedia\ffmpeg\develop\libavdevice\alldevices.c : fatal error
>> C1083: Cannot open compiler generated file:
>> 'D:\Multimedia\ffmpeg\develop\D:\Multimedia\BuildEnv\MSYS2\Multimedi
Hi Ronald,
On 24.01.2016 14:06, Ronald S. Bultje wrote:
> On Sun, Jan 24, 2016 at 6:52 AM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> Thus I object to reverting this before the regression caused by 31741ae is
>> fixed.
>
>
> This is ridiculous, I (who didn't break it an
On 24.01.2016 13:38, Hendrik Leppkes wrote:
> On Sun, Jan 24, 2016 at 12:52 PM, Andreas Cadhalpun
>> Thus I object to reverting this before the regression caused by 31741ae is
>> fixed.
>
> So you break building of git master, and you try to leverage this to
> get your own agenda forward? Serious
Hi,
On Sun, Jan 24, 2016 at 6:52 AM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Thus I object to reverting this before the regression caused by 31741ae is
> fixed.
This is ridiculous, I (who didn't break it and don't even have hw
supporting any of our hwaccel implementatons)
On 1/24/2016 11:52 AM, Andreas Cadhalpun wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
>> Lets just revert this entire batch and re-try after proper testing and
>> review.
>
> You're very quick to suggest a revert here, but very reluctant about reverting
> commit 31741ae. That's not consis
On Sun, Jan 24, 2016 at 12:52 PM, Andreas Cadhalpun
wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
>> The hastly pushed fix doesn't actually work,
>
> It might not work in your environment, but it worked in Charlie's tests.
>
>> all my MSVC fate boxes are still broken, ie.
>> http://fatebeta
On Sun, Jan 24, 2016 at 12:52:37PM +0100, Andreas Cadhalpun wrote:
> On 24.01.2016 03:19, Hendrik Leppkes wrote:
> > The hastly pushed fix doesn't actually work,
>
> It might not work in your environment, but it worked in Charlie's tests.
>
> > all my MSVC fate boxes are still broken, ie.
> > htt
On 24.01.2016 03:19, Hendrik Leppkes wrote:
> The hastly pushed fix doesn't actually work,
It might not work in your environment, but it worked in Charlie's tests.
> all my MSVC fate boxes are still broken, ie.
> http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160123234847
T
On Sat, Jan 23, 2016 at 10:52 PM, James Almer wrote:
> On 1/23/2016 6:44 PM, Andreas Cadhalpun wrote:
>> On 23.01.2016 22:39, Derek Buitenhuis wrote:
>>> On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote:
Do you have a better idea?
>>>
>>> Yes, don't do it, full stop.
>>
>> I could just as well s
On 1/23/2016 6:44 PM, Andreas Cadhalpun wrote:
> On 23.01.2016 22:39, Derek Buitenhuis wrote:
>> On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote:
>>> Do you have a better idea?
>>
>> Yes, don't do it, full stop.
>
> I could just as well suggest you to not use such weird environments.
>
>> Is the fe
On 23.01.2016 22:39, Derek Buitenhuis wrote:
> On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote:
>> Do you have a better idea?
>
> Yes, don't do it, full stop.
I could just as well suggest you to not use such weird environments.
> Is the feature here (bit exact builds out of tree) worth
> all the h
On 1/23/2016 9:36 PM, Andreas Cadhalpun wrote:
> Do you have a better idea?
Yes, don't do it, full stop.
Is the feature here (bit exact builds out of tree) worth
all the hacks? In my gut: no. Several others have expressed
the same opinion.
- Derek
___
On 23.01.2016 22:29, Derek Buitenhuis wrote:
> On 1/23/2016 8:50 PM, Andreas Cadhalpun wrote:
>> On 23.01.2016 13:33, Michael Niedermayer wrote:
>>> On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote:
---
common.mak | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
On 1/23/2016 9:29 PM, Derek Buitenhuis wrote:
> cygwin does not have -W.
>
> Furthermore, makign *environment* deductions based on your *target compiler*
> is incredibly broken.
>
> People also build via msvc with a cygwin shell, and on native linux with
> wine+cl.exe.
>
> - Derek
ARGH, my MUA
On 1/23/2016 8:50 PM, Andreas Cadhalpun wrote:
> On 23.01.2016 13:33, Michael Niedermayer wrote:
>> On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote:
>>> ---
>>> common.mak | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> confirmed to fix checkheaders
>
> Pushed.
On 23.01.2016 13:33, Michael Niedermayer wrote:
> On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote:
>> ---
>> common.mak | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> confirmed to fix checkheaders
Pushed.
Best regards,
Andreas
_
On Sat, Jan 23, 2016 at 12:14:28PM +0100, Andreas Cadhalpun wrote:
> ---
> common.mak | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
confirmed to fix checkheaders
[]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed witho
---
common.mak | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common.mak b/common.mak
index bad2627..5645e2d 100644
--- a/common.mak
+++ b/common.mak
@@ -47,7 +47,8 @@ LDFLAGS:= $(ALLFFLIBS:%=$(LD_PATH)$(DST_PATH)/lib%)
$(LDFLAGS)
define COMPILE
$(call $(1)DE
53 matches
Mail list logo
