Dalibor Topic wrote: > Hi all, > I'm fighting with something rather bizarre in automake 1.8.5 / 1.8d. > In a subdir, my Makefile.am looks like this:
> if COND_KAFFE_X_AWT > MAYBE_KAFFE_X_AWT = X > else > MAYBE_KAFFE_X_AWT = > endif > if COND_KAFFE_QT_AWT > MAYBE_KAFFE_QT_AWT = qt > else > MAYBE_KAFFE_QT_AWT = > endif > if COND_CLASSPATH_GTK_AWT > MAYBE_CLASSPATH_GTK_AWT = classpath-gtk > else > MAYBE_CLASSPATH_GTK_AWT = > endif > SUBDIRS = \ > $(MAYBE_KAFFE_X_AWT) \ > $(MAYBE_KAFFE_QT_AWT) \ > $(MAYBE_CLASSPATH_GTK_AWT) > DIST_SUBDIRS = \ > X \ > qt \ > classpath-gtk Now that you have found your culprit, you can rewrite the above as follows: if COND_KAFFE_X_AWT MAYBE_KAFFE_X_AWT = X endif if COND_KAFFE_QT_AWT MAYBE_KAFFE_QT_AWT = qt endif if COND_CLASSPATH_GTK_AWT MAYBE_CLASSPATH_GTK_AWT = classpath-gtk endif SUBDIRS = \ $(MAYBE_KAFFE_X_AWT) \ $(MAYBE_KAFFE_QT_AWT) \ $(MAYBE_CLASSPATH_GTK_AWT) I.e., let Automake define DIST_SUBDIRS itself, and omit the empty definitions. [...] > with_engine = @with_engine@ > @[EMAIL PROTECTED] = > @[EMAIL PROTECTED] = qt > SUBDIRS = \ > $(MAYBE_KAFFE_X_AWT) \ > $(MAYBE_KAFFE_QT_AWT) \ > $(MAYBE_CLASSPATH_GTK_AWT) > [snip] > @COND_KAFFE_X_AWT_TRUE@ MAYBE_KAFFE_X_AWT = X > @COND_KAFFE_X_AWT_FALSE@ MAYBE_KAFFE_X_AWT = > @COND_CLASSPATH_GTK_AWT_TRUE@ MAYBE_CLASSPATH_GTK_AWT = [...] > which seems to have the weird effect of make *not* recursing into > MAYBE_X_AWT and MAYBE_CLASSPATH_GTK_AWT even if they are defined. My > only explanations is that MAYBE_KAFFE_QT_AWt being in the front > actually gets evaluated for SUBDIRS, while the other MAYBE_* > conditionals are forgotten. The ordering of the variable definitions does not matter. However if your variable definition starts with a tab and comes after a rule in the Makefile (even with interleaved blank lines) then make might read it as a continuation of a rule and not interpret it as a variable definition. This is probably what happened here. If course the reason it appears among the rules in Makefile although it did not in Makefile.am is that Automake's Makefile parser (or shall I call it a sniffer?) cannot deal with <tab>-prefixed variable definition. | # Only recognize leading spaces, not leading tabs. If we recognize | # leading tabs here then we need to make the reader smarter, because | # otherwise it will think rules like `foo=bar; \' are errors. | my $ASSIGNMENT_PATTERN = '^ *([^ \t=:+]*)\s*([:+]?)=\s*(.*)' . "\$"; [...] > Would it be possible to add a warning to automake about such [1] > tabs-vs-spaces oddities? With the current sniffer, this sounds hard. But feel free to give it a try... -- Alexandre Duret-Lutz
