Diego Biurrun <di...@biurrun.de> writes: > On Sat, Oct 20, 2012 at 07:47:51PM +0100, Måns Rullgård wrote: >> Diego Biurrun <di...@biurrun.de> writes: >> > On Sat, Oct 20, 2012 at 06:46:58PM +0100, Måns Rullgård wrote: >> >> Diego Biurrun <di...@biurrun.de> writes: >> >> >> >> > $(FATE_WMA_ENCODE): CMP = stddev >> >> > $(FATE_WMA_ENCODE): REF = >> >> > $(SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav >> >> > >> >> > -FATE_SAMPLES_AVCONV += $(FATE_WMA_ENCODE) >> >> > +FATE_SAMPLES_AVCONV-$(call ENCDEC, WMAV1, ASF) += fate-wmav1-encode >> >> > +FATE_SAMPLES_AVCONV-$(call ENCDEC, WMAV2, ASF) += fate-wmav2-encode >> >> > fate-wma-encode: $(FATE_WMA_ENCODE) >> >> >> >> This makes the fate-wma-encode target fail is one of the encoders is >> >> disabled. >> > >> > Yes, this is an issue; not one restricted to this patch or patchset though. >> > The VC-1 tests, for instance, suffer from a similar issue. >> >> No, they don't. The fate-vc1 target will fail if the VC1 decoder is >> disabled, but in that case running it is completely pointless anyway >> since _all_ the tests depend on that. > > OK. What I mean is that there is a simple way to make fate-vc1 not error > out: > > FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_sa00040 > FATE_SAMPLES_AVCONV-$(CONFIG_VC1_DECODER) += $(FATE_VC1-yes) > ---> > FATE_VC1-$(call DEMDEC, VC1, VC1) += fate-vc1_sa00040 > FATE_SAMPLES_AVCONV += $(FATE_VC1-yes) > > fate-vc1: $(FATE_VC1-yes) > > Then calling "make fate-vc1" will just return instead of throwing an > error. Many (most?) of the test subsets converted so far behave in > this way and it feels more logical and consistent to follow that line.
Why would try to run the fate-vc1 target with the VC1 decoder disabled? *Any* test will fail if you try to run it directly without its dependencies being met. This is no different. > We need to make a policy decision No, we don't. We really don't need formal rules about _everything_. A little common sense works just fine. -- Måns Rullgård m...@mansr.com _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
