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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
