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: 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: 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
"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
"Derek R. Price" wrote: > > > +# 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. Ok, I've removed everything except the package_version & seen_init_automake stuff. The package_version can move to the _AC_TRACE section as soon as it's complete. For now I'm moving it to AC_INIT. I also put a check into init.m4 to warn about obsolescence if PACKAGE &/or VERSION is already set at configure time. Is this the correct approach? If so, I'll send the patch on later. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I know of no safe depository of the ultimate powers of the society but the people themselves, and if we think them not enlightened enough to exercise that control with a wholesome discretion, the remedy is not to take it from them, but to inform their discretion. - Thomas Jefferson, 1820.
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
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_PAC
Re: amtraces
"Derek R. Price" wrote: > Tom Tromey wrote: > > > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > > > Derek> From comp-vars.am: > > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@ > > > > Ok, thanks. > > This is definitely an automake bug. > > Your proposed fix sounds ok to me. > > Patch included. Whoops. Here's the patch for real. Akim, what is the naming scheme you are using for patches. Should I be trying to use something similar? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- The man who reads nothing at all is better educated than the man who reads nothing but newspapers. - Thomas Jefferson (1743-1826) ? automake-DEFAULT_INCLUDES.diff Index: ChangeLog === RCS file: /cvs/automake/ChangeLog,v retrieving revision 1.974 diff -u -r1.974 ChangeLog --- ChangeLog 2001/02/03 05:56:40 1.974 +++ ChangeLog 2001/02/03 22:15:22 @@ -1,3 +1,10 @@ +2001-02-03 Derek Price <[EMAIL PROTECTED]> + + * automake.in (globals): add $(DEFAULT_INCLUDES) to all the COMPILE + definitions which contain DEFS + (lang_c_finish): ditto for ansi2kr _.c target + * comp-vars.am: separate DEFS & DEFAULT_INCLUDES definitions + 2001-02-02 Gordon Sadler <[EMAIL PROTECTED]> * automake.texi (Java Support): Added index, @section. Index: automake.in === RCS file: /cvs/automake/automake.in,v retrieving revision 1.848 diff -u -r1.848 automake.in --- automake.in 2001/02/02 15:10:13 1.848 +++ automake.in 2001/02/03 22:15:26 @@ -341,18 +341,18 @@ &initialize_global_constants; ®ister_language ('c', 'ansi-p=1', 'autodep=', 'flags=CFLAGS', - 'compile=$(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)', + 'compile=$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)', 'compiler-name=COMPILE', 'output-arg=-c', 'c'); ®ister_language ('cxx', 'linker=CXXLINK', 'autodep=CXX', 'flags=CXXFLAGS', - 'compile=$(CXX) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', + 'compile=$(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)', 'compiler-name=CXXCOMPILE', 'output-arg=-c -o $@', 'c++', 'cc', 'cpp', 'cxx', 'C'); ®ister_language ('objc', 'linker=OBJCLINK', 'autodep=OBJC', 'flags=OBJCFLAGS', - 'compile=$(OBJC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_OBJCFLAGS) $(OBJCFLAGS)', + 'compile=$(OBJC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_OBJCFLAGS) $(OBJCFLAGS)', 'compiler-name=OBJCCOMPILE', 'output-arg=-c -o $@', 'm'); @@ -371,7 +371,7 @@ ®ister_language ('asm', 'flags=CFLAGS', # FIXME: asmflags? - 'compile=$(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)', # FIXME: a different compiler? + 'compile=$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)', # FIXME: a different compiler? 'compiler-name=COMPILE', 'output-arg=-c', 's', 'S'); @@ -382,7 +382,7 @@ 'output-arg=-c -o $@', 'f', 'for', 'f90'); ®ister_language ('ppf77', 'linker=F77LINK', 'flags=FFLAGS', - 'compile=$(F77) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)', + 'compile=$(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)', 'compiler-name=PPF77COMPILE', 'output-arg=-c -o $@', 'F'); @@ -395,7 +395,7 @@ # FIXME: for now we can't do dependency tracking for Java. # autodep=GCJ ®ister_language ('java', 'linker=GCJLINK', 'flags=GCJFLAGS', - 'compile=$(GCJ) $(DEFS) $(INCLUDES) $(AM_GCJFLAGS) $(GCJFLAGS)', + 'compile=$(GCJ) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) +$(AM_GCJFLAGS) $(GCJFLAGS)', 'compiler-name=GCJCOMPILE', 'output-arg=-c -o $@', 'java', 'class', 'zip', 'jar'); @@ -5065,7 +5065,7 @@ # we can't use $< -- some makes only define $< during a # suffix rule. $output_rules .= ($base . "_.c: $base.c \$(ANSI2KNR)\n\t" - . '$(CPP) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) ' + . '$(CPP) $(DEFS) $(DEFAUL
Re: amtraces
Tom Tromey wrote: > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> From comp-vars.am: > Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@ > > Derek> Automake subs some compiler include paths into > Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from > Derek> Makefile.ams so that any headers described in AM_CONFIG_HEADER > Derek> can be found during compilation. > > Ok, thanks. > This is definitely an automake bug. > Your proposed fix sounds ok to me. Patch included. > Once we switch over to tracing we can just remove chunks of code from > header-vars.am and other places. That will be nice. Added a FIXME comment to that effect in comp-vars.am since I was there. > We'll need copyright paperwork from you before we can check in any > substantial patch. Still waiting. :) Maybe this chunk is small enough anyhow? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- It is to secure our rights that we resort to government at all. -Thomas Jefferson to M. D'Ivernois, 1795.
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
Tom Tromey <[EMAIL PROTECTED]> writes: > Akim, provided that the changes don't break using automake with an > older autoconf, I trust your judgement on reviewing them. OK, thanks. > I still haven't looked at the --trace code. Anyway, I think it can still change a lot. But reading it is really interesting and demonstrates how good it will be for Automake :) > Ideally we'd have things in shape so that removing the non-trace > code for the release after the next one will be easy. Agreed. Automake 1.5 + sth will AC_PREREQ(2.50) or AC_PREREQ(2.51). Time for simplifications.
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
"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 a
Re: amtraces
> "Akim" == akim <[EMAIL PROTECTED]> writes: Akim> As far as I'm concerned, given that your mark are extremely easy Akim> to remove, given that most messages are from the experimental Akim> code, given that I certainly would like to toy with your Akim> implementation, I'd vote for an inclusion in Automake. Do you Akim> have your papers? :) Akim, provided that the changes don't break using automake with an older autoconf, I trust your judgement on reviewing them. I still haven't looked at the --trace code. Ideally we'd have things in shape so that removing the non-trace code for the release after the next one will be easy. Tom
Re: amtraces
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> From comp-vars.am: Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@ Derek> Automake subs some compiler include paths into Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from Derek> Makefile.ams so that any headers described in AM_CONFIG_HEADER Derek> can be found during compilation. Ok, thanks. This is definitely an automake bug. Your proposed fix sounds ok to me. Once we switch over to tracing we can just remove chunks of code from header-vars.am and other places. That will be nice. We'll need copyright paperwork from you before we can check in any substantial patch. Tom
Re: amtraces
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> The case in question is the DEFAULT_INCLUDES variable being Derek> substituted in as part of DEFS. Since Automake still asumes Derek> that a call to AC_SUBST(DEFS) is always user-requested and that Derek> a user request overrides the version of DEFS from comp-vars.am, Derek> DEFAULT_INCLUDES is no longer being set. I'm afraid I have no idea what this is all about :-(. First, what difference does it make who requests the AC_SUBST? All AC_SUBSTs should end up in Makefile.in. Tom
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_
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
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
Akim Demaille wrote: > "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. 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 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. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This sentance has threee errors. Index: automake.in === RCS file: /cvs/automake/automake.in,v retrieving revision 1.846 diff -u -r1.846 automake.in --- automake.in 2001/02/01 22:51:40 1.846 +++ automake.in 2001/02/02 18:13:49 @@ -311,6 +311,155 @@ # 'md_PATH_PROG', ); +# Keep track of which macros to trace and what data format to use +# +# Bourne shell metachars must be escaped :( +%traced_macro_format = +( + # note that this only works to get the first argument since the second + # and third arguments to AC_CONFIG_FILES are generally shell scripts + # and expecting them not ot contain a comma is probably just too much + 'AC_CONFIG_FILES' => '\\$f:\\$l:\\$n:\\$\\{,\\}%', +); +# callbacks for each invocation of each macro +# +# called as: +# +# &{$hash{ref}}($here, $macro, @args) +# +# where $here is the file:line where the macro was found, $macro is the +# macro being processed, and @args are the args the macro was called with +# +# REFERENCE NOTE: Macro args start at $_[2] :^) +# +# Please try and stick to alphabetical order (minus /^_*A[CM]/) with the +# exceptions of the macros which populate the libobjs arrays, which should be +# reordered and filed at the end of this hash +# +# Hmmm... The macro groupings in scan_one_autoconf_files might make +# more sense, but I skipped it for now since the alphabetizing wasn't my +# request +%traced_macro_function = +( +# Some things required by Automake. +AC_ARG_PROGRAM => sub { $seen_arg_prog = $_[0] }, +AM_C_PROTOTYPES => sub { $am_c_prototypes = $_[0] }, +AC_CANONICAL_HOST => \&scan_autoconf_traces_AC_CANONICAL_HOST, +AC_CANONICAL_SYSTEM => sub { $seen_canonical = $AC_CANONICAL_SYSTEM }, +AC_CHECK_TOOL => \&scan_autoconf_traces_AC_CANONICAL_HOST, +AM_CONDITIONAL => sub { $configure_cond{$_[2]} = $_[0] }, +AC_CONFIG_AUX_DIR => sub { @config_aux_path = $_[2] }, +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, +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'"); + } + }, +AM_ENABLE_MULTILIB => sub { $seen_multilib = $_[0] }, +AC_EXEEXT => sub { $seen_exeext = 1 }, +# Check for NLS support. +AM_GNU_GETTEXT => + sub { # FIXME: eliminate redundant $ac_gettext_line + $seen_gettext = $_[0]; + $ac_gettext_line = (split /:/, $_[0])[1]; + }, +# 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]; + }, +AC_LIBOBJ => sub { $libsources{"$
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?
amtraces
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: 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. 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? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Any sufficiently perverted technology is indistinguishable from Perl.
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_