Re: 14-am-traces.patch

[Akim Demaille <akim at epita dot fr>]

| Akim> +    local ($traces) = "$ENV{amtraces} ";
| 
| Do we really want to use an environment variable?  Eventually automake
| will default to using the autoconf trace facility.  At that time I
| suppose we'll generate a rule in Makefile.in that looks like:
| 
|     $(AUTOMAKE) --autoconf=$(AUTOCONF) ...
| 
| ... and the default will be to use `autoconf'.
| Why not just go ahead and implement that now, with the caveat that
| tracing is only enabled if --autoconf is given?

In fact I first implemented an option `trace' for AUTOMAKE_OPTIONS,
but it didn't work since configure.in is parsed beforehand.  Since
it's only a sketch, since yet it demonstrated some limits of the
current Autoconf (in particular, I'd like to be able to implement some
support for things like:

        elsif (/AM_WITH_REGEX/)
        {
            $libsources{'rx.c'} = 1;
            $libsources{'rx.h'} = 1;
            $libsources{'regex.c'} = 1;
            $libsources{'regex.h'} = 1;
            $omit_dependencies{'rx.h'} = 1;
            $omit_dependencies{'regex.h'} = 1;
        }

the libsources part is trivial, the omit_dependencies is not), I
didn't struggle to have a clean interface.