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 this failed. > +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) > -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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
