[FFmpeg-devel] [PATCH] fate/api: simplify
george at thebuds.net
Mon Jul 6 14:10:14 CEST 2015
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.
> -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
> +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".
> -ifdef SAMPLES
> - FATE_API_SAMPLES += $(FATE_API_SAMPLES-yes)
> -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.
More information about the ffmpeg-devel