[FFmpeg-devel] [PATCH] fate/api: simplify
James Almer
jamrial at gmail.com
Mon Jul 6 19:33:34 CEST 2015
On 06/07/15 9:10 AM, George Boyle wrote:
> This has a couple of implications for the running of these tests in
> certain circumstances. Whether these circumstances are important or
> realistic, I do not know. In particular, I tested by configuring with
> "--disable-avformat" and in that case, "make fate" works fine, but
> necessarily excludes all API tests, and the "fate-api" target will fail
> if SAMPLES isn't set.
This happens with most targets requiring samples. They are skipped if you simply run "make
fate" but will try to run and fail if you call them explicitly.
fate-api-flac will still run before it fails with the h264 test if you call make fate-api.
Now, i'm not sure if there are other similar cases. After a quick glance every explicit
target seems to require samples for all tests or none. This would be the first with mixed
tests.
>
>
>> -FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, H264, H264) += fate-api-h264
>> +FATE_API_SAMPLES-$(call DEMDEC, H264, H264) += fate-api-h264
>> fate-api-h264: $(APITESTSDIR)/api-h264-test$(EXESUF)
>> fate-api-h264: CMD = run $(APITESTSDIR)/api-h264-test $(TARGET_SAMPLES)/h264-conformance/SVA_NL2_E.264
>>
>> -FATE_API_SAMPLES-$(CONFIG_AVFORMAT) += $(FATE_API_SAMPLES_LIBAVFORMAT-yes)
>
> As far as I can tell, $(call DEMDEC, X, Y) does not necessarily imply
> $(CONFIG_AVFORMAT), so "--disable-avformat" led to a condition where
> this failed.
$(call DEMDEC, X, Y) implies the availability of the requested decoder and demuxer.
If said demuxer is still enabled in config.mak after configuring with "--disable-avformat"
then that's probably a build system bug.
>
>
>> +FATE_FFMPEG += $(FATE_API-yes)
>> +FATE_SAMPLES_FFMPEG += $(FATE_API_SAMPLES-yes)
>
> This causes all the API tests to depend on the ffmpeg program. Strictly
> speaking they shouldn't need to, at least for the tests that are
> currently there. And this also explains why "--disable-avformat" will
> exclude the API tests from "make fate".
>
Right, didn't realize this makes it dependent of ffmpeg.
I'll see if i can get around this later. Patch dropped until then.
>
>>
>> -ifdef SAMPLES
>> - FATE_API_SAMPLES += $(FATE_API_SAMPLES-yes)
>> -endif
>> -
>> -FATE_API-$(CONFIG_AVCODEC) += $(FATE_API_LIBAVCODEC-yes)
>> -FATE_API-$(CONFIG_AVFORMAT) += $(FATE_API_LIBAVFORMAT-yes)
>> -FATE_API = $(FATE_API-yes)
>> -
>> -FATE-yes += $(FATE_API) $(FATE_API_SAMPLES)
>> -
>> -fate-api: $(FATE_API) $(FATE_API_SAMPLES)
>> +fate-api: $(FATE_API-yes) $(FATE_API_SAMPLES-yes)
>>
>
> This will add the sample-dependent tests to the "fate-api" target,
> whether or not SAMPLES is set.
>
>
> I guess the question is whether there are a limited number of desired
> use cases to support like "configure && make fate", or the tests should
> be robust to more particular circumstances/configurations (by the way,
> I'm not claiming the existing state covers all bases in that respect).
> If it's the former, then this patch makes things much neater. If it's
> the latter, then the old state seems to cover more cases. Which is
> better is not for me to decide.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
More information about the ffmpeg-devel
mailing list