Re: amtraces
"Derek" == Derek R Price [EMAIL PROTECTED] writes: Ok, thanks. This is definitely an automake bug. Your proposed fix sounds ok to me. Patch included. Derek Whoops. Here's the patch for real. This patch is still big enough that we need paperwork. Derek Akim, what is the naming scheme you are using for patches. Derek Should I be trying to use something similar? Akim usually uses a number and then a short description. You can do this if you like but there's no requirement. Tom
Re: amtraces
These people should be sent the file fencepost.gnu.org:/gd/gnuorg/Copyright/request-assign.future. They fill out the form, return it to me, and I send them the paperwork to sign. If you don't have easy access to fencepost, I'll include the file below. - Brian Youmans, FSF copyright clerk Free Software Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA voice: +1-617-542-5942 fax: +1-617-542-2652 web: http://www.gnu.org --- Please email the following information to [EMAIL PROTECTED], and we will send you the assignment form for your past and future changes. Please use your full name as the subject line of the message. -- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] [For the copyright registration, what country are you a citizen of?] [What year were you born?] [Please write your email address here.] [Please write your postal address here.] [Which files have you changed so far, and which new files have you written so far?]
Re: 31-ac-libsources.patch Re: amtraces
On Feb 5, 2001, Akim Demaille [EMAIL PROTECTED] wrote:
* tests/semantics.at (AC_REPLACE_FUNCS): New test.
* acfunctions.m4 (AC_REPLACE_FUNCS, _AC_LIBOBJ_ALLOCA): Use
AC_LIBSOURCES.
Ok
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: 31-ac-libsources.patch Re: amtraces
"Derek R. Price" [EMAIL PROTECTED] writes: AC_REPLACE_FUNCS is still trying to call AC_LIBOBJ_DECL. :( Pfff, there was no test for AC_REPLACE_FUNCS at all! Thanks! Index: ChangeLog from Akim Demaille [EMAIL PROTECTED] acfunctions.m4 was still using the old AC_LIBOBJ_DECL. Reported by Derek R. Price. * tests/semantics.at (AC_REPLACE_FUNCS): New test. * acfunctions.m4 (AC_REPLACE_FUNCS, _AC_LIBOBJ_ALLOCA): Use AC_LIBSOURCES. Index: THANKS === RCS file: /cvs/autoconf/THANKS,v retrieving revision 1.53 diff -u -u -r1.53 THANKS --- THANKS 2001/01/30 19:29:39 1.53 +++ THANKS 2001/02/05 10:15:58 @@ -32,6 +32,7 @@ Dave Adams [EMAIL PROTECTED] Dave Love [EMAIL PROTECTED] David Morgan [EMAIL PROTECTED] +Derek R. Price [EMAIL PROTECTED] Didier Desseaux[EMAIL PROTECTED] Didier Verna [EMAIL PROTECTED] Dietmar P. Schindler [EMAIL PROTECTED] Index: acfunctions.m4 === RCS file: /cvs/autoconf/acfunctions.m4,v retrieving revision 1.29 diff -u -u -r1.29 acfunctions.m4 --- acfunctions.m4 2001/02/03 13:22:26 1.29 +++ acfunctions.m4 2001/02/05 10:16:00 @@ -92,7 +92,7 @@ # AC_REPLACE_FUNCS(FUNCTION...) # - AC_DEFUN([AC_REPLACE_FUNCS], -[AC_FOREACH([AC_Func], [$1], [AC_LIBOBJ_DECL(AC_Func)])dnl +[AC_FOREACH([AC_Func], [$1], [AC_LIBSOURCE(AC_Func.c)])dnl AC_CHECK_FUNCS([$1], , [_AC_LIBOBJ($ac_func)]) ]) @@ -129,13 +129,13 @@ # - # Set up the LIBOBJ replacement of `alloca'. Well, not exactly # AC_LIBOBJ since we actually set the output variable `ALLOCA'. -# Nevertheless, for Automake, AC_LIBOBJ_DECL it. +# Nevertheless, for Automake, AC_LIBSOURCES it. m4_define([_AC_LIBOBJ_ALLOCA], [# The SVR3 libPW and SVR4 libucb both contain incompatible functions # that cause trouble. Some versions do not even contain alloca or # contain a buggy version. If you still want to use their alloca, # use ar to extract alloca.o from them instead of compiling alloca.c. -AC_LIBOBJ_DECL(alloca) +AC_LIBSOURCES(alloca.c) AC_SUBST(ALLOCA, alloca.$ac_objext)dnl AC_DEFINE(C_ALLOCA, 1, [Define if using `alloca.c'.]) Index: tests/aclocal.m4 === RCS file: /cvs/autoconf/tests/aclocal.m4,v retrieving revision 1.13 diff -u -u -r1.13 aclocal.m4 --- tests/aclocal.m4 2001/01/24 13:19:11 1.13 +++ tests/aclocal.m4 2001/02/05 10:16:00 @@ -53,5 +53,5 @@ grep '^m4_defn([m4_re_word])=' state-env.$1 test $? = 0 || rm -f state-env.$1 -ls -1 | egrep -v '^(state.*|config\.)' | sort state-ls.$1 +ls -1 | egrep -v '^(at-|state-|config\.)' | sort state-ls.$1 ])# AC_STATE_SAVE Index: tests/semantics.at === RCS file: /cvs/autoconf/tests/semantics.at,v retrieving revision 1.19 diff -u -u -r1.19 semantics.at --- tests/semantics.at 2001/01/22 09:03:38 1.19 +++ tests/semantics.at 2001/02/05 10:16:00 @@ -47,6 +47,37 @@ ])]) +# AC_REPLACE_FUNCS +# +# Check that it performs the correct actions: autoconf_ftnirp.c must +# be compiled, and must define HAVE_PRINTF, but not HAVE_AUTOCONF_FTNIRP +# FIXME: Maybe check the traces? +AT_SETUP([AC_REPLACE_FUNCS]) + +AT_DATA([config.in], +[@LIBOBJS@ +]) + +AT_CONFIGURE_AC( +[AC_CONFIG_FILES(config.libobjs:config.in) +AC_REPLACE_FUNCS(printf autoconf_ftnirp)]) + +AT_CHECK_AUTOCONF([-W obsolete]) +AT_CHECK_AUTOHEADER +AT_CHECK_CONFIGURE +AT_CHECK_ENV +AT_CHECK_DEFINES( +[/* #undef HAVE_AUTOCONF_FTNIRP */ +#define HAVE_PRINTF 1 +]) + +AT_CHECK([sed 's/ */ /g;s/^ //;s/ $//' config.libobjs], [], + [autoconf_ftnirp.o +]) + +AT_CLEANUP([config.libobjs]) + + # AC_CHECK_HEADERS # # Check that it performs the correct actions:
Re: amtraces
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
~/src/ace % echo "AC_INIT AC_CANONICAL_SYSTEM" | ace -t AC_CANONICAL_SYSTEM -t
AC_CANONICAL_HOST -
/tmp/ac23991/stdin:1:AC_CANONICAL_SYSTEM:
/tmp/ac23991/stdin:1:AC_CANONICAL_HOST:
i.e., drop AC_CANONICAL_SYSTEM *dead*.
Are you sure? I poked through the code a bit and it looks like AC_CANONICAL_SYSTEM is
now an alias
for AC_CANONICAL_TARGET which requires AC_CANONICAL_HOST but sets some extra variables
which AM seems
to have handlers for as part of its AC_CANONICAL_SYSTEM handling...
+# Some things required by Automake.
+AC_ARG_PROGRAM = sub { $seen_arg_prog = $_[0] },
Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in
having only partial support for this option across configures. In
addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself.
Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT?
+AM_C_PROTOTYPES = sub { $am_c_prototypes = $_[0] },
Should be moved to an Autoconf macro.
+AC_CHECK_TOOL = \scan_autoconf_traces_AC_CANONICAL_HOST,
Sounds wrong: you don't need AC_CANONICAL_HOST to use AC_CHECK_TOOL.
+AM_CONDITIONAL = sub { $configure_cond{$_[2]} = $_[0] },
+AC_CONFIG_AUX_DIR = sub { @config_aux_path = $_[2] },
This macro gives too many problem. Alexandre D. knows what I'm
referring to, I'd like him to start a thread in autoconf@ about this.
Let me know when there's a fix I can use. My basic premise was to convert
scan_one_autoconf_file as
directly as possible while removing the redundancies I could spot.
+AC_CONFIG_FILES = sub { scan_autoconf_config_files ($_[2]) },
+# Handle configuration headers
+AC_CONFIG_HEADER = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AC_CONFIG_HEADERS = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AM_CONFIG_HEADER = \scan_autoconf_traces_AM_CONFIG_HEADER,
Nope, they all point to only AC_CONFIG_HEADERS. Don't trace the others.
This works for AC_CONFIG_HEADERS, but not for AM_CONFIG_HEADER. AM requires
AM_CONFIG_HEADERS to be
used so it needs to catch the call to AC_CONFIG_HEADER so it can warn the user about
their mistake.
+AC_DECL_YYTEXT =
+ sub { unless ($seen_decl_yytext eq $_[0])
+ {
+ $seen_decl_yytext = $_[0];
+ am_conf_line_warning (
+ split (/:/, $_[0]),
+ "\`AC_DECL_YYTEXT' is covered by \`AM_PROG_LEX'");
+ }
+ },
No longer exists, there is only AC_PROG_LEX which includes this.
AM_PROG_LEX is deprecated.
I added obsolete and deprecated warnings for AC_DECL_YYTEXT and AM_PROG_LEX,
respectively.
AC_PROG_LEX is still setting the $seen_decl_yytext variable. Maybe someone will want
to change the
name? I added a comment to this effect.
+AM_ENABLE_MULTILIB = sub { $seen_multilib = $_[0] },
+AC_EXEEXT = sub { $seen_exeext = 1 },
No longer exists, exeext is always computed when there is some
compilation involved, i.e., when Automake wants to use exeext and
obkext, don't check for them: they've been checked for. Or just look
at $ac_subst{EXEEXT}.
Changed the areas in the code to look for $configure_vars{EXEEXT} instead of
$seen_exeext. If these
are always checked for then maybe when tracing is required the special casing can be
removed
entirely.
+# Check for NLS support.
+AM_GNU_GETTEXT =
+ sub { # FIXME: eliminate redundant $ac_gettext_line
+ $seen_gettext = $_[0];
+ $ac_gettext_line = (split /:/, $_[0])[1];
+ },
Why does it need to know this? Hm, will look into the details some day.
+# This macro handles several different things.
+AM_INIT_AUTOMAKE =
+ sub { $seen_make_set = $_[0];
+ $seen_arg_prog = $_[0];
+ $seen_prog_install = $_[0];
+ $package_version = $_[3];
+ $package_version_line = (split /:/, $_[0])[2];
+ $seen_init_automake = $_[0];
+ },
Not good: --trace looks inside, you don't need to know how
AM_INIT_AUTOMAKE is written and what it does. And now the proper
means to set the name/version of a package is via AC_INIT, more
precisely tracing _AC_INIT_PACKAGE. Note that we can introduce a
macro just to ask for the value of an Autoconf macro:
I will examine this more closely. The INSTALL and MAKE_SET stuff I removed already.
/tmp % cat configure.ac nostromo 14:40
AC_INIT(GNU Hello, 1.0)
m4_define([_AC_TRACE])
m4_define([AC_TRACE], [_AC_TRACE(m4_defn([$1]))])
AC_TRACE([AC_PACKAGE_NAME])
AC_TRACE([AC_PACKAGE_TARNAME])
AC_TRACE([AC_PACKAGE_STRING])
AC_TRACE([AC_PACKAGE_VERSION])
/tmp % ace -t _AC_TRACE nostromo 14:40
Re: 31-ac-libsources.patch Re: amtraces
Akim Demaille wrote: FYI, I applied this to Autoconf: 2001-02-03 Akim Demaille [EMAIL PROTECTED] * acfunctions.m4 (AC_FUNC_ERROR_AT_LINE, AC_FUNC_ONSTACK): Use AC_LIBSOURCES. 2001-02-03 Akim Demaille [EMAIL PROTECTED] * acgeneral.m4 (AC_LIBOBJ_DECL): Remove. (AC_LIBSOURCES, AC_LIBSOURCE): New. AC_REPLACE_FUNCS is still trying to call AC_LIBOBJ_DECL. :( Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will finish what I sta I will finish what I sta I will finish what I sta... - Bart Simpson on chalkboard, _The Simpsons_
Re: amtraces
"Derek R. Price" [EMAIL PROTECTED] writes:
Hi Derek, a few more comments on the fly. I have not played with your
patch yet.
All these comments are related to the same idea: Automake must know as
less as possible about macros. It means that if needed, we have to
equip Autoconf with macros which give a generic means to specify
former specialized knowledge, we have to equip existing macros
(Autoconf and Automake) with invocations to these macros etc.
Also, since next Automake will *require* next Autoconf, it is a
perfect moment for making simplifications in both.
Another aspect of the comment is: drop dead old macros. Autoconf by
itself provides the binding to the newer macros, so trace only *new*
macros. Here is an example of what I mean:
~/src/ace % echo "AC_INIT AC_CANONICAL_SYSTEM" | ace -t AC_CANONICAL_SYSTEM -t
AC_CANONICAL_HOST -
/tmp/ac23991/stdin:1:AC_CANONICAL_SYSTEM:
/tmp/ac23991/stdin:1:AC_CANONICAL_HOST:
i.e., drop AC_CANONICAL_SYSTEM *dead*.
+# Some things required by Automake.
+AC_ARG_PROGRAM = sub { $seen_arg_prog = $_[0] },
Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in
having only partial support for this option across configures. In
addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself.
Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT?
+AM_C_PROTOTYPES = sub { $am_c_prototypes = $_[0] },
Should be moved to an Autoconf macro.
+AC_CANONICAL_HOST = \scan_autoconf_traces_AC_CANONICAL_HOST,
+AC_CANONICAL_SYSTEM = sub { $seen_canonical = $AC_CANONICAL_SYSTEM },
Drop this guy dead.
+AC_CHECK_TOOL = \scan_autoconf_traces_AC_CANONICAL_HOST,
Sounds wrong: you don't need AC_CANONICAL_HOST to use AC_CHECK_TOOL.
+AM_CONDITIONAL = sub { $configure_cond{$_[2]} = $_[0] },
+AC_CONFIG_AUX_DIR = sub { @config_aux_path = $_[2] },
This macro gives too many problem. Alexandre D. knows what I'm
referring to, I'd like him to start a thread in autoconf@ about this.
+AC_CONFIG_FILES = sub { scan_autoconf_config_files ($_[2]) },
+# Handle configuration headers
+AC_CONFIG_HEADER = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AC_CONFIG_HEADERS = \scan_autoconf_traces_AC_CONFIG_HEADER,
+AM_CONFIG_HEADER = \scan_autoconf_traces_AM_CONFIG_HEADER,
Nope, they all point to only AC_CONFIG_HEADERS. Don't trace the others.
+AC_DECL_YYTEXT =
+ sub { unless ($seen_decl_yytext eq $_[0])
+ {
+ $seen_decl_yytext = $_[0];
+ am_conf_line_warning (
+ split (/:/, $_[0]),
+ "\`AC_DECL_YYTEXT' is covered by \`AM_PROG_LEX'");
+ }
+ },
No longer exists, there is only AC_PROG_LEX which includes this.
AM_PROG_LEX is deprecated.
+AM_ENABLE_MULTILIB = sub { $seen_multilib = $_[0] },
+AC_EXEEXT = sub { $seen_exeext = 1 },
No longer exists, exeext is always computed when there is some
compilation involved, i.e., when Automake wants to use exeext and
obkext, don't check for them: they've been checked for. Or just look
at $ac_subst{EXEEXT}.
+# Check for NLS support.
+AM_GNU_GETTEXT =
+ sub { # FIXME: eliminate redundant $ac_gettext_line
+ $seen_gettext = $_[0];
+ $ac_gettext_line = (split /:/, $_[0])[1];
+ },
Why does it need to know this? Hm, will look into the details some day.
+# This macro handles several different things.
+AM_INIT_AUTOMAKE =
+ sub { $seen_make_set = $_[0];
+ $seen_arg_prog = $_[0];
+ $seen_prog_install = $_[0];
+ $package_version = $_[3];
+ $package_version_line = (split /:/, $_[0])[2];
+ $seen_init_automake = $_[0];
+ },
Not good: --trace looks inside, you don't need to know how
AM_INIT_AUTOMAKE is written and what it does. And now the proper
means to set the name/version of a package is via AC_INIT, more
precisely tracing _AC_INIT_PACKAGE. Note that we can introduce a
macro just to ask for the value of an Autoconf macro:
/tmp % cat configure.ac nostromo 14:40
AC_INIT(GNU Hello, 1.0)
m4_define([_AC_TRACE])
m4_define([AC_TRACE], [_AC_TRACE(m4_defn([$1]))])
AC_TRACE([AC_PACKAGE_NAME])
AC_TRACE([AC_PACKAGE_TARNAME])
AC_TRACE([AC_PACKAGE_STRING])
AC_TRACE([AC_PACKAGE_VERSION])
/tmp % ace -t _AC_TRACE nostromo 14:40
configure.ac:6:_AC_TRACE:GNU Hello
configure.ac:7:_AC_TRACE:hello
configure.ac:8:_AC_TRACE:GNU Hello 1.0
configure.ac:9:_AC_TRACE:1.0
We can put here and there calls to AC_TRACE to announce variables. Or
just declare an m4_define specialized in ``broadcasted'' variables.
+AC_LIBOBJ = sub { $libsources{"$_[2].c"} = $_[0] },
+_AC_LIBOBJ_DECL =
+ sub { $libsources{"$_[1].c"} = $_[0]
+ unless defined $libsources{"$_[2].c"};
+ },
FYI, I applied this to Autoconf:
2001-02-03 Akim Demaille [EMAIL PROTECTED]
Re: amtraces
"Derek R. Price" [EMAIL PROTECTED] writes: Ok, I found the link on gnu.org on how and why. You can send me the set allowing multiple contributions, and I need an empployer disclaimer. What do you want us to sign? The FSF has recently changed its procedure, and we are all a bit lost. Brian, we have at least three people who are willing to contribute to Automake, and Autoconf (and while we are at it, how about signing for Libtool too?). What should they do? Assignment for past and future changes, if I'm not mistaken. They are: Derek R. Price [EMAIL PROTECTED] Alexandre Duret-Lutz [EMAIL PROTECTED] Tim Van Holder [EMAIL PROTECTED] Thanks, Akim PS/ Please keep us informed.
Re: amtraces
Hm, I'm in favor of having AC_ARG_PROGRAM always run. I see no use in having only partial support for this option across configures. In addition, AM_INIT_AUTOMAKE, IIRC, calls it by itself. Pavel, Alexandre, any problem with integrating AC_ARG_PROGRAM in AC_INIT? An obvious problem is that if AC_CANONICAL_TARGET is used, it should be before AC_ARG_PROGRAM and after AC_INIT, so there will be no place for it. AC_CANONICAL_TARGET should be optional - not every program is a compiler. Probably a dubious feature about $target being the default program prefix will have to be dropped. Alternatively, AC_CANONICAL_TARGET should implement it if the values set by (the former) AC_ARG_PROGRAM are pristine (i.e. the transform rule is trivial). Regards, Pavel Roskin
Re: amtraces
"Derek R. Price" [EMAIL PROTECTED] writes: Ok, I have amtraces code that slurps in almost all the information that scan_one_autoconf_file used to. Unfortuantely I hit a minor snag: We are probably working on the same things. Please, show some code so that we don't duplicate. Since _all_ AC_SUBSTs are being processed now, at least one instance where Automake was allowing for user override is now broken. The case in question is the DEFAULT_INCLUDES variable being substituted in as part of DEFS. I don't understand :( Since Automake still asumes that a call to AC_SUBST(DEFS) is always user-requested and that a user request overrides the version of DEFS from comp-vars.am, DEFAULT_INCLUDES is no longer being set. Since counting the AC_SUBST calls would be painful (each macro would have a different user count threshold and this could be variable), I'm thinking that the best solution is to define an AM_DEFS variable (modeled after AM_CPPFLAGS AM_CFLAGS) and make it part of the COMPILE variable, then subst the old DEFAULT_INCLUDES value into that. Is this the correct approach? I really don't understand what you are talking about... What is DEFAULT_INCLUDES, how does it work?
Re: amtraces
On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
Patch against the current CVS Automake attached. Please excuse all the
"print STDERR"s and my initials littered in comments around the things I was
still working on.
I'm really impressed! Your work is impressive, congratulations! I'm
especially impressed by the fact you already turn *off* the scanning
of .ac files, which clear demonstrates how evolved your patch is!
As far as I'm concerned, given that your mark are extremely easy to
remove, given that most messages are from the experimental code, given
that I certainly would like to toy with your implementation, I'd vote
for an inclusion in Automake. Do you have your papers? :)
I'd make one simple comment: I would not trust `:' as a separator, I'd
play with more unlikely separators. See the Autoconf documentation,
which, for instance, shows:
-
Much freedom is given over the FORMAT:
$ autoconf -t 'AC_SUBST:ac_subst{"$1"} = "$f:$l";'
ac_subst{"ECHO_C"} = "configure.ac:2";
ac_subst{"ECHO_N"} = "configure.ac:2";
ac_subst{"ECHO_T"} = "configure.ac:2";
More traces deleted
The long SEPARATORs can be used to ease parsing of complex structures:
$ autoconf -t 'AM_MISSING_PROG:${|:|}*'
ACLOCAL|:|aclocal|:|$missing_dir
AUTOCONF|:|autoconf|:|$missing_dir
AUTOMAKE|:|automake|:|$missing_dir
More traces deleted
-
In fact I designed the traces precisely thinking of this other implementation:
instead of having code to parse the traces, issue --trace requests so
that you'd only have to source the result. Obviously I didn't know
at that time one has to write $ac_subst{} :)
I have no idea whether this plan was good or not, I just wanted to let
you know the original idea behind --trace.
I really don't understand what you are talking about... What is
DEFAULT_INCLUDES, how does it work?
From comp-vars.am:
DEFS = @DEFS@@DEFAULT_INCLUDES@
Automake subs some compiler include paths into @DEFAULT_INCLUDES@ during the
creation of Makefile.ins from Makefile.ams so that any headers described in
AM_CONFIG_HEADER can be found during compilation.
Unfortuantely, it will not do this if it thinks AC_SUBST(DEFS) was called by
configure.ac. Before amtraces this meant that the user had called
AC_SUBST(DEFS) themselves and asumedly wanted to override Automake's
definition of DEFS.
Now I think the structure of the comp-vars.am will need to be changed to
define some var other than DEFS to @DEFAULT_INCLUDES@ and then that var
should be included as part of the COMPILE makefile variable.
I didn't look into the details, but can't we have some variable initialized
in the top of configure.in which trigger this default behavior?
Re: amtraces
[EMAIL PROTECTED] wrote:
On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote:
Akim Demaille wrote:
"Derek R. Price" [EMAIL PROTECTED] writes:
Patch against the current CVS Automake attached. Please excuse all the
"print STDERR"s and my initials littered in comments around the things I was
still working on.
I'm really impressed! Your work is impressive, congratulations! I'm
Thanks. :) I tried to write a macro for CVS which made use of AC_FOREACH and
Automake couldn't handle it anymore. I had to do _something_.
that I certainly would like to toy with your implementation, I'd vote
for an inclusion in Automake. Do you have your papers? :)
No, actually. I probably should too, seeing as I've been hacking on CVS for a
couple of years now. :) Can someone send them to me? I'd actually be
interested in learning the maintainer side of the process too since I'm probably
supposed to be doing some of this for CVS, if anyone could send me a link?
I'd make one simple comment: I would not trust `:' as a separator, I'd
play with more unlikely separators. See the Autoconf documentation,
I figured, but : was already being used and seems to work well enough in most
cases. If you look at my code, it should be easy to change the default. You can
even change the FORMAT string on a per-macro basis by tweaking the
%traced_macro_format hash. I've only had to do that for AC_CONFIG_FILES so far,
since that's the only macro my test base was passing arguments to in dest:source
format, but I imagine it would be necessary for AC_CONFIG_HEADER and any other
macro that takes filename arguments in that format. Maybe tweaking the default
to something like you suggest would be easiest:
The long SEPARATORs can be used to ease parsing of complex structures:
$ autoconf -t 'AM_MISSING_PROG:${|:|}*'
ACLOCAL|:|aclocal|:|$missing_dir
AUTOCONF|:|autoconf|:|$missing_dir
AUTOMAKE|:|automake|:|$missing_dir
More traces deleted
On a side note, I think we could move to the multi-line inputs if we needed to
with only a little extra work, but right now my code still counts on single line
inputs.
Now I think the structure of the comp-vars.am will need to be changed to
define some var other than DEFS to @DEFAULT_INCLUDES@ and then that var
should be included as part of the COMPILE makefile variable.
I didn't look into the details, but can't we have some variable initialized
in the top of configure.in which trigger this default behavior?
If I understood what you are suggesting, I don't think so, because the
information is stored in several of the template files. Well, you could, but
I don't think switching between template files is the right idea here. Anyhow,
as I understand things, the change I am suggesting shouldn't break backwards
compatibility. I just wanted to see if an Automake guru could confirm that I was
on the right track.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
That liberty [is pure] which is to go to all, and not to the few or the rich
alone.
- Thomas Jefferson to H. Gates, 1798.
Re: amtraces
"Derek R. Price" wrote: [EMAIL PROTECTED] wrote: On Fri, Feb 02, 2001 at 01:17:13PM -0500, Derek R. Price wrote: Akim Demaille wrote: that I certainly would like to toy with your implementation, I'd vote for an inclusion in Automake. Do you have your papers? :) No, actually. I probably should too, seeing as I've been hacking on CVS for a couple of years now. :) Can someone send them to me? I'd actually be interested in learning the maintainer side of the process too since I'm probably supposed to be doing some of this for CVS, if anyone could send me a link? Ok, I found the link on gnu.org on how and why. You can send me the set allowing multiple contributions, and I need an empployer disclaimer. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I wouldn't bring up Paris right now. It's poor salesmanship. - Humphrey Bogart as Rick, _Casablanca_
amtraces functionality
The amtraces functionality for AC_CONFIG_FILES is totally broken. Anyone mind if I spend a few minutes on it? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I don't suffer from stress. I'm a carrier. - Scott Adam's _Dilbert_
