automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 14-am-traces.patch


From: Akim Demaille
Subject: Re: 14-am-traces.patch
Date: 29 Jan 2001 18:33:11 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Crater Lake)

| 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]