On Wed, 22 May 2013, Martin Storsjö wrote:
On Wed, 22 May 2013, Diego Biurrun wrote:
During each make run, the build system checks that any specified
dependencies
do actually exist, to prevent typos and other errors from fouling up
correct
dependency settings. However, it also causes make to trip up when new
components have been added to the code, but not yet registered in the build
system by configure. A manual configure call is required in this case.
The "config" target is designed precisely to reinitialize the build without
having to manually call configure. Skip the dependency check when running
the "config" target to allow automatic reconfiguration in such cases.
---
So this has way too wordy a log message and the comment could also be
improved.
Plus, it's not exactly an epitome of beauty in the first place.
But it works automatically without the need for setting environment
variables.
tests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tests/Makefile b/tests/Makefile
index 939490b..157d20c 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -20,7 +20,11 @@ tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) |
tests/data
tests/data/asynth% tests/data/vsynth%.yuv tests/vsynth%/00.pgm: TAG = GEN
+# Do not check existence of config variables when reconfiguring to allow
new
+# config variables getting registered in the build system.
+ifneq ($(MAKECMDGOALS),config)
CHKCFG = $(if $($(1))$(!$(1)),$($(1)), $(error No such config: $(1)))
+endif
ALLYES = $(strip $(call XYES, $(1)))
XYES = $(if $(strip $(1)), \
--
1.7.9.5
This probably works pretty well, and I'm ok with it. Another target that
might be worth adding here is fate-rsync - iirc Janne had a setup where he
ran make fate-rsync on a not-reconfigured setup somewhere that, started
failing for this reason.
"make clean" is another one you might want to run without having all the
deps in place. Yes it might not remove all the exact right files if you've
updated the code tree compared to when the files were built, but you might
still want to call it.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel