Re: Weird behavior with multiple conditionals in single Makefile.am

[Alexandre Duret-Lutz]

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@
> @address@hidden =
> @address@hidden = 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