On Fri, 13 Dec 2019, James Almer wrote:
On 12/13/2019 8:07 PM, Martin Storsjö wrote:
I intentionally meant to use a different variable for that, to
differentiate between the configure-generated CONFIG_LARGE_TESTS from
config.mak and the one that is set to pick up a potential user-supplied
value from e.g. LARGE_TESTS, otherwise falling back on the configure
generated value - I'm not sure if that really works if the first and
last variable are the same, or if that ends up as an infinite recursion
otherwise (CONFIG_LARGE_TESTS expands to LARGE_TESTS which expands to
CONFIG_LARGE_TESTS).
I still think just overriding using CONFIG_LARGE_TESTS from the command
line is more than enough for a developer debug option, but if others
want something shorter then your suggestion above for ALLYES is fine.
FWIW, I think it can be handled pretty neatly in two different ways, at
the bottom of config.mak:
CONFIG_LARGE_TESTS:=$(if $(LARGE_TESTS), $(LARGE_TESTS), $(CONFIG_LARGE_TESTS))
This also is picked up if you'd have "export LARGE_TESTS=no; ... other
stuff ... ; make fate". Picking up random unprefixed variables like this
might not be ideal.
Alternatively, slightly weirder looking but guarding against that, would
be:
# If LARGE_TESTS=foo is set on the make command line, this is ignored
LARGE_TESTS:=$(CONFIG_LARGE_TESTS)
# Overwrite CONFIG_LARGE_TESTS with whatever LARGE_TESTS was set to.
CONFIG_LARGE_TESTS:=$(LARGE_TESTS)
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
