1 files changed, 49 insertions, 0 deletions
diff --git a/tiger-compiler/tcsh/README-deps.txt b/tiger-compiler/tcsh/README-deps.txt
new file mode 100644
index 0000000..8e3fa60
--- /dev/null
+++ b/tiger-compiler/tcsh/README-deps.txt
@@ -0,0 +1,49 @@
+* Handling dependencies of SWIG-generated files.        -*- outline -*-
+
+
+** The problem with non-Automade dependencies
+
+Sometimes, the dependencies computed by swig in tcsh/python/.deps and
+tcsh/ruby/.deps are void because of some changes in the build
+environment (e.g., SWIG has been installed somewhere else since the
+last build, and dependencies on SWIG's .swg files are no longer
+valid).  Hence SWIG wrappers won't build, because of unmet
+dependencies.
+
+_build % make -C tcsh/ruby
+make: Entering directory `/home/levill_r/src/tc/_build/tcsh/ruby'
+make: *** No rule to make target `/home/levill_r/local/share/swig/1.3.29/swig.swg', needed by `tiger_misc-wrap.cc'.  Stop.
+make: Leaving directory `/home/levill_r/src/tc/_build/tcsh/ruby'
+
+In the previous example, I (Roland) wasn't able to build TCSH/Ruby
+because I had updated from SWIG 1.3.29 (installed locally) to 1.3.31
+(provided by Debian).
+
+** Solution
+
+Our approach is to provide a target to reset the dependencies (i.e.,
+to set them to the initial state set by `configure').  `make
+deps-reset' provides that service, erasing dependencies generated by
+swig.
+
+_build % make -C tcsh/ruby deps-reset
+make: Entering directory `/home/levill_r/src/tc/_build/tcsh/ruby'
+make: Leaving directory `/home/levill_r/src/tc/_build/tcsh/ruby'
+
+The build can then proceed.
+
+_build % make -C tcsh/ruby
+make: Entering directory `/home/levill_r/src/tc/_build/tcsh/ruby'
+if /usr/bin/swig -c++ -ruby -I../../../lib -I../../../src  -MD -MF ".deps/tiger_misc-wrap.Tcc" -o tiger_misc-wrap.cc ../../../lib/misc/tiger_misc.i; \
+        then \
+          mv -f ".deps/tiger_misc-wrap.Tcc" ".deps/tiger_misc-wrap.Pcc"; \
+        else \
+          rm -f ".deps/tiger_misc-wrap.Tcc"; exit 1; \
+        fi
+
+[...]
+
+
+Note: I don't know whether Automake is smart enough to handle this
+problem gracefully with the dependencies it already handles.  If so,
+please tell us!