This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: 14-am-traces.patch
- To: Akim Demaille <akim at epita dot fr>
- Subject: Re: 14-am-traces.patch
- From: Tom Tromey <tromey at redhat dot com>
- Date: 28 Jan 2001 19:10:49 -0700
- Cc: Automake <automake at gnu dot org>
- List-Id: Discussion list for automake <automake.gnu.org><mailto:automake-request@gnu.org?subject=unsubscribe>
- References: <E14MuUF-0006V4-00@nostromo.lrde.epita.fr>
- Reply-To: tromey at redhat dot com
>>>>> "Akim" == Akim Demaille <akim@epita.fr> writes:
Akim> * automake.in (&scan_autoconf_config_files): Extract from
Akim> &scan_one_autoconf_file.
Akim> (&scan_one_autoconf_file): Use it.
Akim> (&scan_autoconf_traces): New.
Akim> ($scan_autoconf_files): Use it.
This is fine.
I have a question though.
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?
(And for now we wouldn't document --autoconf in automake --help or in
the manual.)
Tom