Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation
[+cc: automake-patches, bug-libtool] [re-sending because delivery to automake and autoconf lists failed] References: http://lists.gnu.org/archive/html/autoconf-patches/2012-10/msg7.html http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg0.html On 11/01/2012 07:05 PM, Nick Bowler wrote: Hi Stefano, sorry for the delay. Hi Nick, and thanks for the testing. On 2012-10-31 11:03 +0100, Stefano Lattarini wrote: On 10/23/2012 12:59 AM, Nick Bowler wrote: I am going to try all these patches to automake/autoconf/libtool soon; I will report back with the results! Has anybody had a chance to try these patches? If not, does anyone object to the idea of committing them anyway, and see how things work out? It doesn't seem we're near to a release, so there's ample time to revert these changes before cutting Autoconf 2.70, in case they won't work as expected, or will reveal unforeseen issues. I got a chance to try these. I applied the patches on top of latest git autoconf and automake, as of today, and also checked out latest git libtool. I tried converting a package to use these, which originally had ACLOCAL_AMFLAGS = -I m4 -I common/m4. I removed the ACLOCAL_AMFLAGS from Makefile.am and added AC_CONFIG_MACRO_DIRS([m4 common/m4]) to configure.ac. Here are some initial observations: 1) Newlines can be used to separate items in AC_CONFIG_FILES, etc. However, aclocal explodes if you try to do this with AC_CONFIG_MACRO_DIRS: Use of uninitialized value $macro in exists at /tmp/autotools-test/bin/aclocal line 753, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 760, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 764, GEN40 line 2. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 768, GEN40 line 2. Use of uninitialized value $macro in exists at /tmp/autotools-test/bin/aclocal line 753, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 755, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 760, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 764, GEN82 line 3. Use of uninitialized value $macro in string eq at /tmp/autotools-test/bin/aclocal line 768, GEN82 line 3. This strikes me as extremely odd because the output of autoconf --trace AC_CONFIG_MACRO_DIRS is the same in either case. I can reproduce the problem. The patch below enhances the automake testsuite in order to catch it. I hope I'll be able to come up with a fix soon enough. 2) Git libtool seems broken, as libtoolize is deleting files installed by gnulib-tool into the snippet directory. This breaks the build. I suspect the problem is unrelated to the AC_CONFIG_MACRO_DIRS change, but git libtool was required to test it. 3) Libtoolize still complains that ACLOCAL_AMFLAGS is not set in Makefile.am, but the warning seems harmless and it nevertheless prints that it has picked up AC_CONFIG_MACRO_DIRS. I believe these issues should be reported to the libtool developers, so I've added the bug-libtool list in CC:. 4) I get a bunch of new warnings from aclocal, of the form: configure.ac:42: warning: DX_EXPORTED_SH is m4_require'd but not m4_defun'd The invocation comes from an AC_REQUIRE([DX_EXPORTED_SH]) and the DX_EXPORTED_SH macro is expected to be picked up by aclocal -- it is, and things seem to work in the end, but the warnings are annoying (and are printed multiple times). And you say they weren't there before these series? Or is this regression already present in master? I'll investigate. Other than requiring a manual workaround for item #2, everything seems to be working at a first glance. I can cook up some test cases for these issues if necessary. For the automake part, there should be no need of test cases: your description is clear and precise enough that I can cook up some myself, and that will save hassles with copyright issues and assignment forms. These all look like fixable problems to me. Cheers, Thanks again, Stefano 8 8 8 8 8 8 8 8 8 From
Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation
On 2012-11-02 10:46 +0100, Stefano Lattarini wrote: On 10/23/2012 12:59 AM, Nick Bowler wrote: 4) I get a bunch of new warnings from aclocal, of the form: configure.ac:42: warning: DX_EXPORTED_SH is m4_require'd but not m4_defun'd The invocation comes from an AC_REQUIRE([DX_EXPORTED_SH]) and the DX_EXPORTED_SH macro is expected to be picked up by aclocal -- it is, and things seem to work in the end, but the warnings are annoying (and are printed multiple times). And you say they weren't there before these series? Or is this regression already present in master? I'll investigate. It wasn't there before changing the package to use AC_CONFIG_MACRO_DIRS instead of ACLOCAL_AMFLAGS. In previous versions of Automake these same warnings will show up when invoking aclocal without any -I options. In this case, not passing those arguments would be an error, and the resulting configure sript would probably not work since aclocal can't find the macros in question. But now, aclocal is being called with no -I options intentionally, and it is actually finding the macros (and producing working configure scripts), but these warnings are still being printed. Adding the -I options again makes the warnings go away. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation
On 11/02/2012 02:36 PM, Nick Bowler wrote: On 2012-11-02 10:46 +0100, Stefano Lattarini wrote: On 10/23/2012 12:59 AM, Nick Bowler wrote: 4) I get a bunch of new warnings from aclocal, of the form: configure.ac:42: warning: DX_EXPORTED_SH is m4_require'd but not m4_defun'd The invocation comes from an AC_REQUIRE([DX_EXPORTED_SH]) and the DX_EXPORTED_SH macro is expected to be picked up by aclocal -- it is, and things seem to work in the end, but the warnings are annoying (and are printed multiple times). And you say they weren't there before these series? Or is this regression already present in master? I'll investigate. It wasn't there before changing the package to use AC_CONFIG_MACRO_DIRS instead of ACLOCAL_AMFLAGS. In previous versions of Automake these same warnings will show up when invoking aclocal without any -I options. In this case, not passing those arguments would be an error, and the resulting configure sript would probably not work since aclocal can't find the macros in question. But now, aclocal is being called with no -I options intentionally, and it is actually finding the macros (and producing working configure scripts), but these warnings are still being printed. Adding the -I options again makes the warnings go away. OK, I've exposed this issue with the patch below. Let's see if I'll manage to fix it as quickly as the other one... Thanks, Stefano 8 8 8 8 8 8 8 8 8 From 87232828c0c59253ae88c81295cb9048089c7952 Mon Sep 17 00:00:00 2001 Message-Id: 87232828c0c59253ae88c81295cb9048089c7952.1351877539.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Fri, 2 Nov 2012 18:12:40 +0100 Subject: [PATCH] coverage: expose a bug in aclocal (spurious warnings) When some macro expanded in configure.ac calls AC_REQUIRE on another macro that is defined in one of the local m4 macro dirs specified with one of the macros AC_CONFIG_MACRO_DIRS or AC_CONFIG_MACRO_DIR, aclocal prints spurious warnings like: configure.ac:4: warning: MY_BAR is m4_require'd but not m4_defun'd configure.ac:3: MY_FOO is expanded from... Expose this weakness in our testsuite. Reported by Nick Bowler; see point (4) of: http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg0.html * t/aclocal-macrodir.tap (AC_CONFIG_MACRO_DIR interaction with AC_REQUIRE): New test. * t/aclocal-macrodirs.tap (AC_CONFIG_MACRO_DIRS interaction with AC_REQUIRE): Likewise. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- t/aclocal-macrodir.tap | 27 ++- t/aclocal-macrodirs.tap | 33 - 2 files changed, 58 insertions(+), 2 deletions(-) diff --git a/t/aclocal-macrodir.tap b/t/aclocal-macrodir.tap index 4114edb..c48b31f 100755 --- a/t/aclocal-macrodir.tap +++ b/t/aclocal-macrodir.tap @@ -20,7 +20,7 @@ am_create_testdir=empty . test-init.sh -plan_ 5 +plan_ 6 ocwd=$(pwd) || fatal_ getting current working directory ACLOCAL_PATH=; unset ACLOCAL_PATH @@ -173,4 +173,29 @@ test_end #--- +test_begin AC_CONFIG_MACRO_DIR interaction with AC_REQUIRE TODO + +cat configure.ac 'END' +AC_INIT([req], [1.0]) +AC_CONFIG_MACRO_DIR([macro-dir]) +AC_DEFUN([MY_FOO], [AC_REQUIRE([MY_BAR])]) +MY_FOO +END + +mkdir macro-dir +echo 'AC_DEFUN([MY_BAR], [//my//bar//])' macro-dir/x.m4 + +st=0; $ACLOCAL 2stderr || st=$? +cat stderr 2 + +test $st -eq 0 \ + test ! -s stderr \ + $FGREP 'm4_include([macro-dir/x.m4])' aclocal.m4 \ + $AUTOCONF \ + not $EGREP 'MY_(FOO|BAR)' configure \ + $FGREP '//my//bar//' configure \ + || r='not ok' + +test_end + : diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap index 81ca75e..3007ed4 100755 --- a/t/aclocal-macrodirs.tap +++ b/t/aclocal-macrodirs.tap @@ -26,7 +26,7 @@ am_create_testdir=empty END } || skip_all_ autoconf doesn't define the AC_CONFIG_MACRO_DIRS macro -plan_ 12 +plan_ 13 ocwd=$(pwd) || fatal_ getting current working directory ACLOCAL_PATH=; unset ACLOCAL_PATH @@ -341,4 +341,35 @@ test_end #--- +test_begin AC_CONFIG_MACRO_DIRS interaction with AC_REQUIRE TODO + +cat configure.ac 'END' +AC_INIT([req], [1.0]) +AC_CONFIG_MACRO_DIRS([m1 m2]) +AC_DEFUN([MY_FOO], [ + AC_REQUIRE([MY_BAR]) + AC_REQUIRE([MY_BAZ]) +]) +MY_FOO +END + +mkdir m1 m2 +echo 'AC_DEFUN([MY_BAR], [^^my^^bar^^])' m1/x.m4 +echo 'AC_DEFUN([MY_BAZ], [~~my~~baz~~])' m2/x.m4 + +st=0; $ACLOCAL 2stderr || st=$? +cat stderr 2 + +test $st -eq 0 \ + test ! -s stderr \ + $FGREP 'm4_include([m1/x.m4])' aclocal.m4 \ + $FGREP 'm4_include([m2/x.m4])' aclocal.m4 \ + $AUTOCONF \ + not $EGREP 'MY_(FOO|BAR|BAZ)' configure \ + $FGREP '^^my^^bar^^' configure \ + $FGREP '~~my~~baz~~' configure \ + || r='not ok' + +test_end + : -- 1.8.0 Cheers,
[PATCH] warn: new special syntax warning, hack for aclocal (was: Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation)
Reference:
http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg4.html
On 11/02/2012 07:34 PM, Stefano Lattarini wrote:
Well, it turns out that such warnings are coming from the autom4te
invocation, so I see no simple, non-hacky way to avoid them, unless
we add a knob to autom4te itself.
So, autoconfers: would be OK with you to add a new warning category
to autom4te that would suppress *only* this specific warning?
The warning in question being
AC_FOO is m4_require'd but not m4_defun'd
that is emitted by the '_m4_require_call' internal macro (defined in
'lib/m4sugar/m4sugar.m4').
Oh well, I went on and wrote a patch anyway. It should be good to go,
maybe modulo the name of the new singleton warnings category; if anyone
has a better name to suggest, shoot!
Regards,
Stefano
8 8 8 8 8 8 8 8 8
From f5f17fa1b2bccdd29101f7eb1eefe8c4dabe4ad3 Mon Sep 17 00:00:00 2001
Message-Id:
f5f17fa1b2bccdd29101f7eb1eefe8c4dabe4ad3.1351885649.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 2 Nov 2012 20:14:53 +0100
Subject: [PATCH] warn: new special syntax warning, hack for aclocal
We introduce a new special warning category, m4require-without-m4defun,
meant to contain only those warnings caused m4 macros that m4_require'd
but not m4_defun'd. This category is automatically implied by '-Wsyntax',
but can be disabled without disabling the other warnings in the syntax
category.
This new category is introduced exclusively to allow aclocal to process
AC_CONFIG_MACRO_DIRS without emitting spurious warnings. In fact, if
aclocal doesn't suppress that special warnings, then, when some macro
expanded in configure.ac calls AC_REQUIRE on another macro that is defined
in one of the local m4 macro dirs specified with AC_CONFIG_MACRO_DIRS, the
*first* autom4te invocation issued by aclocal, not yet being able to see
the m4 macro definitions in the local m4 dirs, will prints spurious
warnings like:
configure.ac:4: warning: MY_BAR is m4_require'd but not m4_defun'd
configure.ac:3: MY_FOO is expanded from...
Expose this weakness in our testsuite.
Originally reported by Nick Bowler; see point (4) of:
http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg0.html
* lib/Autom4te/ChannelDefs.pm (m4require-without-m4defun): New channel,
enabled by default.
(switch_warning): Special handling for it: silence it when '-Wno-syntax'
is given, enable it when '-Wsyntax' is given.
* lib/m4sugar/m4sugar.m4 (_m4_require_call): Give warnings in the new
m4require-without-m4defun category, rather than in the 'syntax' one.
* tests/m4sugar.at (m4@t@_warn): Enhance.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
lib/Autom4te/ChannelDefs.pm | 14 ++
lib/m4sugar/m4sugar.m4 | 7 ++-
tests/m4sugar.at| 21 +
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/lib/Autom4te/ChannelDefs.pm b/lib/Autom4te/ChannelDefs.pm
index 0d5b5c4..af67059 100644
--- a/lib/Autom4te/ChannelDefs.pm
+++ b/lib/Autom4te/ChannelDefs.pm
@@ -152,6 +152,11 @@ register_channel 'obsolete', type = 'warning', silent =
1;
register_channel 'override', type = 'warning', silent = 1;
register_channel 'portability', type = 'warning', silent = 1;
register_channel 'syntax', type = 'warning';
+# Special kind of syntax error that we must be able to silence
+# individually in order to support AC_CONFIG_MACRO_DIRS in aclocal.
+# For more background, see:
+# http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg4.html
+register_channel 'm4require-without-m4defun', type = 'warning';
register_channel 'unsupported', type = 'warning';
register_channel 'verb', type = 'debug', silent = 1, ordered = 0;
@@ -274,6 +279,15 @@ sub switch_warning ($)
elsif (channel_type ($cat) eq 'warning')
{
setup_channel $cat, silent = $has_no;
+ # Handling of syntax warnings is trickier, due to the hack
+ # necessary to support AC_CONFIG_MACRO_DIRS in aclocal.
+ if ($cat eq 'syntax')
+{
+ # '-Wsyntax' must enable warnings in the hack category
+ # 'm4require-without-m4defun', while '-Wno-syntax' must
+ # disable them.
+ setup_channel 'm4require-without-m4defun', silent = $has_no;
+}
}
else
{
diff --git a/lib/m4sugar/m4sugar.m4 b/lib/m4sugar/m4sugar.m4
index 12a9ab7..c1b1029 100644
--- a/lib/m4sugar/m4sugar.m4
+++ b/lib/m4sugar/m4sugar.m4
@@ -2080,13 +2080,18 @@ m4_if([$0], [m4_require], [[m4_defun]],
[[AC_DEFUN]])['d macro])])]dnl
#
# This is called frequently, so minimize the number of macro invocations
# by avoiding dnl and other overhead on the common path.
+# The use of convoluted warning category 'm4require-without-m4defun' is
+# an hack required by aclocal to support AC_CONFIG_MACRO_DIRS without
+# risking spurious warnings; for more background, see:
+#
Re: [PATCH 0/2] AC_CONFIG_MACRO_DIRS: implementation and documentation
On 11/02/2012 12:34 PM, Stefano Lattarini wrote: Well, it turns out that such warnings are coming from the autom4te invocation, so I see no simple, non-hacky way to avoid them, unless we add a knob to autom4te itself. So, autoconfers: would be OK with you to add a new warning category to autom4te that would suppress *only* this specific warning? The warning in question being AC_FOO is m4_require'd but not m4_defun'd that is emitted by the '_m4_require_call' internal macro (defined in 'lib/m4sugar/m4sugar.m4'). Maybe not a new syntax category, but a way to selectively disable just that warning. I'm thinking of adding a witness macro; something like wrapping the existing [m4_warn([syntax]...)] within _m4_require_call inside an m4_ifdef([_m4_require_no_warning]) probe; then we supply a trivial definition of the _m4_require_no_warning witness macro in its own .m4f file. Then we can modify lib/autom4te.in so that the Autoconf-without-aclocal-m4 language does not use the dedicated file (ergo, the witness is not present and there is no warning issued when encountering required macros); but the Autoconf, Autotest, Automate, M4sh, and M4sugar languages DO use the dedicated file and therefore get the warning. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] warn: new special syntax warning, hack for aclocal
On 11/02/2012 01:49 PM, Stefano Lattarini wrote: Reference: http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg4.html On 11/02/2012 07:34 PM, Stefano Lattarini wrote: Well, it turns out that such warnings are coming from the autom4te invocation, so I see no simple, non-hacky way to avoid them, unless we add a knob to autom4te itself. So, autoconfers: would be OK with you to add a new warning category to autom4te that would suppress *only* this specific warning? The warning in question being AC_FOO is m4_require'd but not m4_defun'd that is emitted by the '_m4_require_call' internal macro (defined in 'lib/m4sugar/m4sugar.m4'). Oh well, I went on and wrote a patch anyway. It should be good to go, maybe modulo the name of the new singleton warnings category; if anyone has a better name to suggest, shoot! Hmm, your idea turned out to be relatively simple; fewer lines than the attempt I had of adding a new file to some but not all of the autom4te languages to conditionally control the warning. +++ b/lib/m4sugar/m4sugar.m4 @@ -2080,13 +2080,18 @@ m4_if([$0], [m4_require], [[m4_defun]], [[AC_DEFUN]])['d macro])])]dnl # # This is called frequently, so minimize the number of macro invocations # by avoiding dnl and other overhead on the common path. +# The use of convoluted warning category 'm4require-without-m4defun' is +# an hack required by aclocal to support AC_CONFIG_MACRO_DIRS without s/an hack/a hack/ (The rule of thumb is that if the 'h' is aspirated, as in hack, then you use 'a'; if the 'h' is silent, as in hour, then use 'an') ACK with that fix; and assuming I ever get around to reviewing the other two patches that add AC_CONFIG_MACRO_DIRS in the first place (looking at them now...) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
On 11/02/2012 02:46 PM, Eric Blake wrote: +++ b/lib/autoconf/general.m4 @@ -1727,13 +1727,21 @@ AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl ## ## +# AC_CONFIG_MACRO_DIRS(DIR-1 [DIR-2 ... DIR-n]) +# +# Declare directories containing additional macros for aclocal. +# This macro can be called multiple times, and with multiple arguments. +AC_DEFUN([AC_CONFIG_MACRO_DIRS], []) Rather, I think we need this (and this also works with my above goal of triggering an AC_CONFIG_MACRO_DIR trace exactly once): # _AC_CONFIG_MACRO_DIRS_USED(CALLER) # -- # Witness macro that says whether the first macro dir has been listed, # in order to fail on incorrect usage. Self-redefining, so that all # but the first call check who CALLER is, and error if needed. m4_define([_AC_CONFIG_MACRO_DIRS_USED], [m4_define([$0], [m4_if([$1], [AC_CONFIG_MACRO_DIR], [AC_MSG_ERROR([$1 cannot be used multiple times])])])]) I wrote these off the cuff while composing the email, so they are relatively untested. And while re-reading, I see I botched the self-redefinition, as well as failed to call AC_CONFIG_MACRO_DIR if the first use was AC_CONFIG_MACRO_DIRS. Here's another attempt, again relatively untested. # _AC_CONFIG_MACRO_DIR(DIR) # - # Declare a single directory containing additional macros for aclocal; # can be called more than once; order of calls is important. This # macro exists solely for tracing. AC_DEFUN([_AC_CONFIG_MACRO_DIR]) # _AC_CONFIG_MACRO_DIRS_HELPER(CALLER, DIR) # - # Internal engine that coordinates between the public macros to # eventually trace DIR as another macro dir; uses self-redefinition # to error on incorrect usage, depending on CALLER. Recurses through # AC_CONFIG_MACRO_DIR on first call if needed for legacy tracing. # Do not bother tracing this. m4_define([_AC_CONFIG_MACRO_DIRS_HELPER], [m4_if([$1], [AC_CONFIG_MACRO_DIR], [_AC_CONFIG_MACRO_DIR([$2])], [AC_CONFIG_MACRO_DIR([$2])])m4_define([$0], m4_defn([$0_])]) # _AC_CONFIG_MACRO_DIRS_HELPER_(CALLER, DIR) # -- # Second definition of _AC_CONFIG_MACRO_DIRS_HELPER. # Do not bother tracing this. m4_define([_AC_CONFIG_MACRO_DIRS_HELPER_], [_AC_CONFIG_MACRO_DIR($[2])m4_if($[1], [AC_CONFIG_MACRO_DIR], [AC_MSG_ERROR([$1 cannot be used multiple times])])]) # AC_CONFIG_MACRO_DIRS(DIR1 [DIR2...]) # # Declare one or more whitespace-separated directory containing # additional macros for aclocal; can be called more than once; # order of calls is important. Trace _AC_CONFIG_MACRO_DIR # instead of this. AC_DEFUN([AC_CONFIG_MACRO_DIRS], [m4_map_args_w([$1], [_$0_HELPER([$0], ], [)])]) # AC_CONFIG_MACRO_DIR(DIR) # # Declare a single directory containing additional macros for aclocal; # must be called at most once, and before any AC_CONFIG_MACRO_DIRS. # Legacy applications traced this, although it is recommended that # newer applications trace _AC_CONFIG_MACRO_DIR instead. We guarantee # that this macro will be traced at most once in a valid configure.ac. AC_DEFUN([AC_CONFIG_MACRO_DIR], [_$0S_HELPER([$0], [$1])]) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
On 11/02/2012 03:19 PM, Eric Blake wrote: I wrote these off the cuff while composing the email, so they are relatively untested. And while re-reading, I see I botched the self-redefinition, as well as failed to call AC_CONFIG_MACRO_DIR if the first use was AC_CONFIG_MACRO_DIRS. Here's another attempt, again relatively untested. Self-redefinition is a bit complex; how about this alternative? # _AC_CONFIG_MACRO_DIRS_USED # -- # Witness macro defined to - after the first macro dir is traced. m4_define([_AC_CONFIG_MACRO_DIRS_USED]) # _AC_CONFIG_MACRO_DIR(DIR) # - # Declare a single directory containing additional macros for aclocal; # can be called more than once; order of calls is important. This # macro exists solely for tracing. AC_DEFUN([_AC_CONFIG_MACRO_DIR], [m4_define([$0S_USED], [-])]) # _AC_CONFIG_MACRO_DIRS_HELPER(CALLER, DIR) # - # Internal engine that coordinates between the public macros to # eventually trace DIR as another macro dir; uses self-redefinition # to error on incorrect usage, depending on CALLER. Recurses through # AC_CONFIG_MACRO_DIR on first call if needed for legacy tracing. # Do not bother tracing this. m4_define([_AC_CONFIG_MACRO_DIRS_HELPER], [m4_if([$1], [AC_CONFIG_MACRO_DIRS], [AC_CONFIG_MACRO_DIR([$2])], [$1], [-AC_CONFIG_MACRO_DIR], [AC_MSG_ERROR([AC_CONFIG_MACRO_DIR cannot be used multiple times], [_AC_CONFIG_MACRO_DIR([$2])])]) # AC_CONFIG_MACRO_DIRS(DIR1 [DIR2...]) # # Declare one or more whitespace-separated directory containing # additional macros for aclocal; can be called more than once; # order of calls is important. Trace _AC_CONFIG_MACRO_DIR # instead of this. AC_DEFUN([AC_CONFIG_MACRO_DIRS], [m4_map_args_w([$1], [_$0_HELPER(_$0_USED()[$0], ], [)])]) # AC_CONFIG_MACRO_DIR(DIR) # # Declare a single directory containing additional macros for aclocal; # must be called at most once, and before any AC_CONFIG_MACRO_DIRS. # Legacy applications traced this, although it is recommended that # newer applications trace _AC_CONFIG_MACRO_DIR instead. We guarantee # that this macro will be traced at most once in a valid configure.ac. AC_DEFUN([AC_CONFIG_MACRO_DIR], [_$0S_HELPER(_$0S_USED()[$0], [$1])]) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] docs: ACLOCAL_AMFLAGS will become obsolescent in Automake 1.13
On 10/17/2012 04:15 AM, Stefano Lattarini wrote:
See commit 'v1.12.1-165-gcd1a9cc' aclocal: deprecate ACLOCAL_AMFLAGS,
trace AC_CONFIG_MACRO_DIR instead in the Automake git repository.
See also follow-up discussion at:
http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html
* doc/autoconf.texi (@node Input @defmac AC_CONFIG_MACRO_DIRS): Adjust.
(autoreconf Invocation): Warn about the possible future removal of
ACLOCAL_AMFLAGS support from Automake.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
doc/autoconf.texi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1d80a6d..852ae22 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -1816,7 +1816,9 @@ If you want @command{autoreconf} to pass flags that are
not listed here
on to @command{aclocal}, set @code{ACLOCAL_AMFLAGS} in your
@file{Makefile.am}.
Due to a limitation in the Autoconf implementation these flags currently
must be set on a single line in @file{Makefile.am}, without any
-backslash-newlines.
+backslash-newlines. Also, be aware that future Automake release might
+start flagging @code{ACLOCAL_AMFLAGS} as obsolescent, or even remove
+support for it.
Context based on my comments of patch 1 may require touching up this hunk.
@c = Initialization and Output Files.
@@ -2131,8 +2133,8 @@ AC_CONFIG_MACRO_DIRS([dir4 dir5])
should cause the directories to be searched in this order:
@samp{dir1 dir2 dir3 dir4 dir5}.
-Note that if you use @command{aclocal} from Automake to generate
-@file{aclocal.m4}, you must also set
+Note that if you use @command{aclocal} from an Automake release prior to
+1.13 to generate @file{aclocal.m4}, you must also set
@code{ACLOCAL_AMFLAGS = -I @var{dir1} [-I @var{dir2} ... -I @var{dirN}]}
in your top-level @file{Makefile.am}. Due to a limitation in
the Autoconf implementation of @command{autoreconf}, these include
ACK.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal
Oops, I should have answered to this before writing my last reply ...
On 11/02/2012 09:46 PM, Eric Blake wrote:
On 10/17/2012 04:15 AM, Stefano Lattarini wrote:
Similar to AC_CONFIG_MACRO_DIR, but accepts more than one argument.
This will allow projects to use several m4 macro local dirs. This is
especially important for projects that are used as nested subpackages
of larger projects.
See also:
http://lists.gnu.org/archive/html/autoconf/2011-12/msg00037.html
http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00010.html
* lib/autoconf/general.m4 (AC_CONFIG_MACRO_DIRS): New. Expands to the
empty anyway, since it is only meant to be traced by tools like aclocal
and autoreconf.
Hmm, I'm wondering if we should do something fancier, and have both
AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS collaborate so that the
FIRST call to either macro causes AC_CONFIG_MACRO_DIR to be traced.
Considering that I'd like to see AC_CONFIG_MACRO_DIR deprecated in
Autoconf 2.71 and removed in Autoconf 2.72, I believe that would be
a bit of an overkill. I think that we should just assume that, if
a user calls AC_CONFIG_MACRO_DIR, he calls it just once, and without
mixing it with AC_CONFIG_MACRO_DIRS (like he would have done anyawy
with Autoconf = 2.69). Or am I assuming too much?
In fact, I think that we _shouldn't_ trace AC_CONFIG_MACRO_DIRS, but
should instead trace _AC_CONFIG_MACRO_DIR,
Give that such tracing would be *the* interface for third-party tools
to interact with out new feature, I'd rather have such a macro named
so that it's clear it is a public macro. Maybe something as simple as
AC_CONFIG_MACRO_DIRS_TRACE_ME would be enough?
where AC_CONFIG_MACRO_DIRS
has the task of whitespace normalizing and iterating over the loop.
That way, backends like aclocal do not have to repeat whitespace
normalization,
Actually, doing whitespace normalization in aclocal is a good idea regardless
IMHO, as it would allow us to remove extra indirections from macros like
AM_EXTRA_RECURSIVE_TARGETS -- as suggested by the commit message of
http://lists.gnu.org:443/archive/html/automake-patches/2012-11/msg5.html
and don't have to worry if the user passed newlines or
even backslash-newline in their AC_CONFIG_MACRO_DIRS call.
Backslash-newline seems to be handled just fine by the ${::}% normalization
in the autom4te's '--trace' options, as show by the tests introduced here:
http://lists.gnu.org:443/archive/html/automake-patches/2012-11/msg4.html
(AC_CONFIG_MACRO_DIR): Updated comments to mark it as obsolescent. It
does not elicit warnings yet, for backward-compatibility.
* doc/autoconf.texi (@node Input): Document AC_CONFIG_MACRO_DIRS rather
than to the obsolescent AC_CONFIG_MACRO_DIR.
* NEWS: Update.
Suggested-by: Eric Blake ebl...@redhat.com
Helped-by: Nick Bowler nbow...@elliptictech.com
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
NEWS| 9 +
doc/autoconf.texi | 36 ++--
lib/autoconf/general.m4 | 10 +-
3 files changed, 44 insertions(+), 11 deletions(-)
diff --git a/NEWS b/NEWS
index d3ff4b9..495266a 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,15 @@ GNU Autoconf NEWS - User visible changes.
** Macros
+- AC_CONFIG_MACRO_DIRS
+ Use this macro to declare the directory for local M4 macros for aclocal.
s/the directory/one or more directories/
Consider this fixed.
+ It will be supported by future versions of aclocal (starting from the
+ Automake 1.13 release).
+
+- AC_CONFIG_MACRO_DIR
+ This macro is now obsolescent. AC_CONFIG_MACRO_DIRS Should be used
+ instead.
But for backward compatibility with existing tools such as libtool, you
may use a single AC_CONFIG_MACRO_DIR call prior to any
AC_CONFIG_MACRO_DIRS calls.
not with my existing aclocal enhancements. For backward compatibility,
you can use AC_CONFIG_MACRO_DIR by itself (as was possible with autoconf
2.70 and automake 1.13); but that's it. And given the general
uselessness of AC_CONFIG_MACRO_DIR, trying to get more fancy than that
that sounds like a waste of time to me.
+++ b/doc/autoconf.texi
@@ -2106,19 +2106,35 @@ files. For instance it is called by macros like
@code{AC_PROG_INSTALL}
@end defmac
Similarly, packages that use @command{aclocal} should declare where
-local macros can be found using @code{AC_CONFIG_MACRO_DIR}.
+local macros can be found using @code{AC_CONFIG_MACRO_DIRS}.
+
+@defmac AC_CONFIG_MACRO_DIRS (@var{dir1} [@var{dir2} ... @var{dirN}])
+@acindex{CONFIG_MACRO_DIRS}
+Specify the given directories as the location of additional local Autoconf
+macros. This macro is intended for use by future versions of commands like
+@command{autoreconf} or @command{aclocal} that trace macro calls; it should
+be called directly from @file{configure.ac} so that tools that install
+macros for @command{aclocal} can find the macros' declarations.
+
+This macro
Re: [PATCH] warn: new special syntax warning, hack for aclocal
On 11/02/2012 09:22 PM, Eric Blake wrote: On 11/02/2012 01:49 PM, Stefano Lattarini wrote: Reference: http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg4.html On 11/02/2012 07:34 PM, Stefano Lattarini wrote: Well, it turns out that such warnings are coming from the autom4te invocation, so I see no simple, non-hacky way to avoid them, unless we add a knob to autom4te itself. So, autoconfers: would be OK with you to add a new warning category to autom4te that would suppress *only* this specific warning? The warning in question being AC_FOO is m4_require'd but not m4_defun'd that is emitted by the '_m4_require_call' internal macro (defined in 'lib/m4sugar/m4sugar.m4'). Oh well, I went on and wrote a patch anyway. It should be good to go, maybe modulo the name of the new singleton warnings category; if anyone has a better name to suggest, shoot! Hmm, your idea turned out to be relatively simple; fewer lines than the attempt I had of adding a new file to some but not all of the autom4te languages to conditionally control the warning. +++ b/lib/m4sugar/m4sugar.m4 @@ -2080,13 +2080,18 @@ m4_if([$0], [m4_require], [[m4_defun]], [[AC_DEFUN]])['d macro])])]dnl # # This is called frequently, so minimize the number of macro invocations # by avoiding dnl and other overhead on the common path. +# The use of convoluted warning category 'm4require-without-m4defun' is +# an hack required by aclocal to support AC_CONFIG_MACRO_DIRS without s/an hack/a hack/ Consider this fixed. I will post a re-spin of the patch series tomorrow anyway; so you'll be able to double-check then. (The rule of thumb is that if the 'h' is aspirated, as in hack, then you use 'a'; if the 'h' is silent, as in hour, then use 'an') ACK with that fix; and assuming I ever get around to reviewing the other two patches that add AC_CONFIG_MACRO_DIRS in the first place (looking at them now...) Regards, Stefano
AC_CHECK_LIB for C++ libraries
Hey everyone, I am currently writing configure.ac and Makefile.am files for a project I have been working on. The project consists of some C++ shared libraries and one executable. If they were C libraries I could just use AC_CHECK_LIB([lib1], [function1]) to check whether the library lib1 is available. This does not work with C++ libraries. Is there a similar way of doing this for C++ libraries? I could not find anything helpful online and would appreciate any help! Thanks a lot! Cheers Jan ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Passing options to libtool from within a GNU Autotools project.
Hello all. Does anybody know how to pass additional options to libtool from within a GNU Autotools project? I need to pass the ; --preserve-dup-deps option to libtool from within my Autotools project. I'm not sure if I need to specify this option within my configure.ac file, if it should be specified when I invoke the generated configure script, or how I should otherwise go about it. I'd like to think that I can specify this libtool option from within my configure.ac file, thus relieving any potential users of my package from having to specify this option when they invoke the generated configure script. If anyone can help me out with this matter then it would be greatly appreciated. Thanks in advance for any assistance. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_LIB for C++ libraries
On 11/2/12 9:04 PM, Jan Mikelson wrote: Hey everyone, I am currently writing configure.ac and Makefile.am files for a project I have been working on. The project consists of some C++ shared libraries and one executable. If they were C libraries I could just use AC_CHECK_LIB([lib1], [function1]) to check whether the library lib1 is available. This does not work with C++ libraries. Is there a similar way of doing this for C++ libraries? I could not find anything helpful online and would appreciate any help! Thanks a lot! I've used AC_LINK_IFELSE to check for C++ libs. Cheers, Peter ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_LIB for C++ libraries
On Sat, 2012-11-03 at 00:14 +1000, Peter Johansson wrote: On 11/2/12 9:04 PM, Jan Mikelson wrote: Hey everyone, I am currently writing configure.ac and Makefile.am files for a project I have been working on. The project consists of some C++ shared libraries and one executable. If they were C libraries I could just use AC_CHECK_LIB([lib1], [function1]) to check whether the library lib1 is available. This does not work with C++ libraries. Is there a similar way of doing this for C++ libraries? I could not find anything helpful online and would appreciate any help! Thanks a lot! I've used AC_LINK_IFELSE to check for C++ libs. Cheers, Peter Hey Peter, thanks for your reply, but how exactly do you do this? If you don't have time to explain it, I would very much appreciate it, if you could point me to a documentation, where I could read it up. Thank you very much! Cheers Jan ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Passing options to libtool from within a GNU Autotools project.
Craig, Just add it to LDFLAGS and it will get added to the link line. If you're building a libtool library: libname_la_LDFLAGS = -preserve-dup-deps or a program prgname_LDFLAGS = -preserve-dup-deps On 11/02/12 08:00, Craig Sanders wrote: Hello all. Does anybody know how to pass additional options to libtool from within a GNU Autotools project? I need to pass the ; --preserve-dup-deps option to libtool from within my Autotools project. I'm not sure if I need to specify this option within my configure.ac file, if it should be specified when I invoke the generated configure script, or how I should otherwise go about it. I'd like to think that I can specify this libtool option from within my configure.ac file, thus relieving any potential users of my package from having to specify this option when they invoke the generated configure script. If anyone can help me out with this matter then it would be greatly appreciated. Thanks in advance for any assistance. _ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
